From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: NFSv4/pNFS possible POSIX I/O API standards Date: Thu, 30 Nov 2006 12:29:50 +0000 Message-ID: <20061130122950.GA28757@infradead.org> References: <6.2.3.4.2.20061127213243.04f786c0@cic-mail.lanl.gov> <20061128055428.GA29891@infradead.org> <20061129090450.GA16296@infradead.org> <20061129094815.GE6429@schatzie.adilger.int> <1164795907.3752.58.camel@quoit.chygwyn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andreas Dilger , linux-fsdevel@vger.kernel.org, Gary Grider , Christoph Hellwig Return-path: Received: from pentafluge.infradead.org ([213.146.154.40]:21906 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S936359AbWK3M3y (ORCPT ); Thu, 30 Nov 2006 07:29:54 -0500 To: Steven Whitehouse Content-Disposition: inline In-Reply-To: <1164795907.3752.58.camel@quoit.chygwyn.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Nov 29, 2006 at 10:25:07AM +0000, Steven Whitehouse wrote: > I agree that this is a good plan, but I'd been looking at this idea from > a different direction recently. The in kernel NFS server calls > vfs_getattr from its filldir routine for readdirplus and this means not > only are we unable to optimise performance by (for example) sorting > groups of getattr calls so that we read the inodes in disk block order, > but also that its effectively enforcing a locking order of the inodes on > us too. Since we can have async locking in GFS2, we should be able to do > "lockahead" with readdirplus too. > > I had been considering proposing a readdirplus export operation, but > since this thread has come up, perhaps a file operation would be > preferable as it could solve two problems with one operation? Doing this as an export operation is wrong. Even if it's only used for nfsd for now the logical level this should be on are the file operations. If you do it you could probably prototype a syscall for it aswell - once we have the infrastructure the syscall should be no more than about 20 lines of code.