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). 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? Thanks, Lucho - 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
