Re: NFSv4/pNFS possible POSIX I/O API standards

[Peter Staubach <staubach@redhat.com>]

Matthew Wilcox wrote:
> On Tue, Dec 05, 2006 at 05:47:16PM +0100, Latchesar Ionkov wrote:
>   
>> I think that the main problem is that all these file systems resove a
>> path name, one directory at a time bringing the server to its knees by
>> the huge amount of requests. I would like to see what the performance
>> is if you a) cache the last few hundred lookups on the server side,
>> and b) modify VFS and the file systems to support multi-name lookups.
>> Just assume for a moment that there is no any way to get these new
>> operations in (which is probaly going to be true anyway :). What other
>> solutions can you think of? :)
>>     
>
> How exactly would you want a multi-name lookup to work?  Are you saying
> that open("/usr/share/misc/pci.ids") should ask the server "Find usr, if
> you find it, find share, if you find it, find misc, if you find it, find
> pci.ids"?  That would be potentially very wasteful; consider mount
> points, symlinks and other such effects on the namespace.  You could ask
> the server to do a lot of work which you then discard ... and that's not
> efficient.

It could be inefficient, as pointed out, but defined right, it could
greatly reduce the number of over the wire trips.

The client can already tell from its own namespace when a submount may
be encountered, so know not to utilize the multicomponent pathname
lookup facility.  The requirements could state that the server stops
when it encounters a non-directory/non-regular file node in the namespace.
This sort of thing...

       ps