From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: NFSv4/pNFS possible POSIX I/O API standards Date: Wed, 29 Nov 2006 01:48:15 -0800 Message-ID: <20061129094815.GE6429@schatzie.adilger.int> References: <6.2.3.4.2.20061127213243.04f786c0@cic-mail.lanl.gov> <20061128055428.GA29891@infradead.org> <20061129090450.GA16296@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Gary Grider , linux-fsdevel@vger.kernel.org Return-path: Received: from mail.clusterfs.com ([206.168.112.78]:16043 "EHLO mail.clusterfs.com") by vger.kernel.org with ESMTP id S1757664AbWK2JsR (ORCPT ); Wed, 29 Nov 2006 04:48:17 -0500 To: Christoph Hellwig Content-Disposition: inline In-Reply-To: <20061129090450.GA16296@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.