hi,

> > > Let me rephrase that, as I now see I might have been unclear. I thought a
> > > big part of wanting VOP_REMOVE() to only take the directory and the name
> > > component (not the vnode itself) was to save actually looking it up in
> > > namei(9) - VOP_LOOKUP() would no longer have DELETE lookups. If we don't
> > > have that vnode in the fs-indep code, though, how do we tell if there is a
> > > file system mounted on it?
> > 
> > i think that mount(2) can remember the (dvp, name) pair so that
> > it can be checked without the being removed vnode itself.
> 
> Hmmm... It could.
> 
> However that would mean that each mount point sits on two vnodes, one for 
> the node and one for the parent.

is it a problem?

> I'd rather either leave things as they are, or just put a cached-node 
> lookup in each file system + mount point check as part of the VOP_REMOVE() 
> code.

IMO, mount points belong to the upper layer rathar than each filesystems.
it'd be better to put the code where it logically belongs to.

> Also, is there any way NFS Exporting a file system could cause a mount 
> point to get renamed, thus invalidating the above cache?

i see no reason to keep the current behaviour for such a weird usage.
it'd be enough to return eg. EPERM.

YAMAMOTO Takashi