hi,

> > > For ufs, AFAICT we add two int32_t's to hold slot information. We also 
> > > use these values for file creation. So it doesn't seem like a waste to me.
> > 
> > it's a waste because the members are only used during dirops.
> > you can implement an internal version of ufs_lookup, which stores slot info
> > into kernel stack or somewhere instead of the in-core inode, and
> > call it from dirop VOPs.
> 
> I really think you're adding a lot of complexity for two ints.

i don't think so.  it's rather simpler and is a better abstraction.

besides, it isn't merely a matter of space.
it's one of reasons why we can't allow concurrent operations on a directory.

> How much code are we talking about? Is it really worth making ourselves 
> incompatable with all the other BSDs for this?

yes, i think.

> One other option is to keep the calling code pattern the same, and add a 
> NOLOAD flag. Its semantics are we do the lookup, and we灑eturn the vnode 
> if it is in core, but we don't load a vnode in if there isn't one now. My 
> idea is that since the parent directory will be locked the whole time, no 
> one can come in and create an entry behind our back. Thus this would be a 
> case where it's valid to return NULL with no error from namei(). This 
> change would mean continuing to cache slot info, but I think that'll be 
> fine.

i think it works.
however, i don't think it's worth to keep the current code pattern hardly.
anyway it should be changed eventually, IMO.

YAMAMOTO Takashi