From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ric Wheeler Subject: Re: NFSv4/pNFS possible POSIX I/O API standards Date: Fri, 01 Dec 2006 10:52:59 -0500 Message-ID: <45704FDB.50109@emc.com> 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> Reply-To: ric@emc.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mexforward.lss.emc.com ([128.222.32.20]:63190 "EHLO mexforward.lss.emc.com") by vger.kernel.org with ESMTP id S967590AbWLAPx2 (ORCPT ); Fri, 1 Dec 2006 10:53:28 -0500 To: Christoph Hellwig , Gary Grider , linux-fsdevel@vger.kernel.org In-Reply-To: <20061129094815.GE6429@schatzie.adilger.int> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Andreas Dilger wrote: > On Nov 29, 2006 09:04 +0000, Christoph Hellwig wrote: >> - readdirplus >> >> This one is completely unneeded as a kernel API. Doing readdir >> plus calls on the wire makes a lot of sense and we already do >> that for NFSv3+. Doing this at the syscall layer just means >> kernel bloat - syscalls are very cheap. > > The question is how does the filesystem know that the application is > going to do readdir + stat every file? It has to do this as a heuristic > implemented in the filesystem to determine if the ->getattr() calls match > the ->readdir() order. If the application knows that it is going to be > doing this (e.g. ls, GNU rm, find, etc) then why not let the filesystem > take advantage of this information? If combined with the statlite > interface, it can make a huge difference for clustered filesystems. > > I think that this kind of heuristic would be a win for local file systems with a huge number of files as well... ric