On Wed, 2006-12-06 at 18:12 -0500, Latchesar Ionkov wrote: > On 12/5/06, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Tue, Dec 05, 2006 at 05:55:14PM +0100, Latchesar Ionkov wrote: > > > What is your opinion on giving the file system an option to lookup a > > > file more than one name/directory at a time? I think that all remote > > > file systems can benefit from that? > > > > Do you mean something like the 4.4BSD namei interface where the VOP_LOOKUP > > routine get the entire remaining path and is allowed to resolve as much of > > it as it can (or wants)? > > > > While this allows remote filesystems to optimize deep tree traversals it > > creates a pretty big mess about state that is kept on lookup operations. > > > > For Linux in particular it would mean doing large parts of __link_path_walk > > in the filesystem, which I can't thing of a sane way to do. > > The way I was thinking of implementing it is leaving all the hard > parts of the name resolution in __link_path_walk and modifying inode's > lookup operation to accept an array of qstrs (and its size). lookup > would also check and revalidate the dentries if necessary (usually the > same operation as looking up a name for the remote filesystems). I beg to differ. Revalidation is not the same as looking up: the locking rules are _very_ different. > lookup will check if it reaches symbolic link or mountpoint and will > stop resolving any further. __link_path_walk will use the name to fill > an array of qstrs (we can choose some sane size of the array, like 8 > or 16), then call (directly or indirectly) ->lookup (nd->flags will > reflect the flags for the last element in the array), check if the > inode of the last dentry is symlink, and do what it currently does for > symlinks. > > Does that make sense? Am I missing anything? Again: locking. How do you keep the dcache sane while the filesystem is doing a jumble of revalidation and new lookups. Trond - 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
