hi,

> I think we have two, remote and local.

i think "remove vs local" is too aggressive simplification.
although i don't argue much about it because anyway i agree our in-tree
filesystem implementations fall into one of two classes.

> > > Other than that, what do we need to do? What semantics do we need to add 
> > > or change?
> > 
> > don't forget about "CREATE on negative cache" case.
> 
> Ok. Right now, the in-tree cache_lookup() removes a negative entry on the
> CREATE case.  I think that is the correct behavior. Do you think we need 
> to do something different?

cache_lookup() removes entry and returns -1 while
not all filesystems need non-cached lookup for CREATE.

besides, IMHO, updating entries in cache_lookup is just evil.
it should be occured only when the operation succeed.
ie. each dirop VOPs should update namecache instead.
if you feel it as code duplication, i think we can introduce
cache_update_after_remove, etc. to minimize duplication.

> > > Put another way, I think we can change our current name cache routines to 
> > > support remote file system semantics in addition to supporting local file 
> > > system semantics. I think these changes will be smaller than the changes 
> > > you just proposed.
> > 
> > how in particular?
> 
> I'll attach a diff. To be honest, it's your initial diff with the one
> change I wanted made to it. It should fix everything I understand we have
> wrong. What behaviors do you want to change about it?

if you're removing a directory entry, and there's a negative namecache
entry for it, there's no need to do non-cached lookup even for
ufs and friends.  ie. just returning ENOENT should be fine.

YAMAMOTO Takashi