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
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
