From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Latchesar Ionkov" Subject: Re: Re: NFSv4/pNFS possible POSIX I/O API standards Date: Wed, 6 Dec 2006 18:12:35 -0500 Message-ID: References: <20061203015203.GA5656@schatzie.adilger.int> <20061204073200.GB5637@schatzie.adilger.int> <1165245336.711.176.camel@lade.trondhjem.org> <4574C48A.8030007@mcs.anl.gov> <1165298200.5776.26.camel@lade.trondhjem.org> <20061205100748.GC5871@infradead.org> <20061205221205.GB1988@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Trond Myklebust" , "Rob Ross" , "Andreas Dilger" , "Sage Weil" , "Brad Boyer" , "Anton Altaparmakov" , "Gary Grider" , linux-fsdevel@vger.kernel.org Return-path: Received: from nf-out-0910.google.com ([64.233.182.191]:46551 "EHLO nf-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S937769AbWLFXMh (ORCPT ); Wed, 6 Dec 2006 18:12:37 -0500 Received: by nf-out-0910.google.com with SMTP id o25so699746nfa for ; Wed, 06 Dec 2006 15:12:35 -0800 (PST) To: "Christoph Hellwig" In-Reply-To: <20061205221205.GB1988@infradead.org> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 12/5/06, Christoph Hellwig 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