From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Ross Subject: Re: NFSv4/pNFS possible POSIX I/O API standards Date: Wed, 06 Dec 2006 11:27:20 -0600 Message-ID: <4576FD78.4040603@mcs.anl.gov> 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> <4575E9B0.3060908@mcs.anl.gov> <20061205220538.GA1988@infradead.org> <45760702.6040805@redhat.com> <20061206100614.GX5937@schatzie.adilger.int> <4576FBB0.2070704@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , Trond Myklebust , Sage Weil , Brad Boyer , Anton Altaparmakov , Gary Grider , linux-fsdevel@vger.kernel.org Return-path: Received: from mailgw.mcs.anl.gov ([140.221.9.4]:40383 "EHLO mailgw.mcs.anl.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935447AbWLFR1X (ORCPT ); Wed, 6 Dec 2006 12:27:23 -0500 To: Ulrich Drepper In-Reply-To: <4576FBB0.2070704@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Ulrich Drepper wrote: > Andreas Dilger wrote: >> Does this mean you are against the statlite() API entirely, or only >> against >> the document's use of the flag as a vague "accuracy" value instead of a >> hard "valid" value? > > I'm against fuzzy values. I've no problems with a bitmap specifying > that certain members are not wanted or wanted (probably the later, zero > meaning the optional fields are not wanted). Thanks for clarifying. >> IMHO, if the application doesn't need a particular field (e.g. "ls -i" >> doesn't need size, "ls -s" doesn't need the inode number, etc) why should >> these be filled in if they are not easily accessible? As for what is >> easily accessible, that needs to be determined by the filesystem itself. > > Is the size not easily accessible? It would surprise me. If yes, then, > by all means add it to the list. I'm not against extending the list of > members which are optional if it makes sense. But certain information > is certainly always easily accessible. File size is definitely one of the more difficult of the parameters, either because (a) it isn't stored in one place but is instead derived, or (b) because a lock has to be obtained to guarantee consistency of the returned value. >> That was previously suggested by me already. IMHO, there should ONLY be >> a statlite variant of readdirplus(), and I think most people agree with >> that part of it (though there is contention on whether readdirplus() is >> needed at all). > > Indeed. Given there is statlite and we have d_type information, in most > situations we won't need more complete stat information. Outside of > programs like ls that is. > > Part of why I wished the lab guys had submitted the draft to the > OpenGroup first is that this way they would have to be more detailed on > why each and every interface they propose for adding is really needed. > Maybe they can do it now and here. What programs really require > readdirplus? I can't speak for everyone, but "ls" is the #1 consumer as far as I am concerned. Regards, Rob