From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [PATCH 1/2] [RFC] vfs: 'stat light' fstatat flags Date: Tue, 7 Apr 2009 19:13:15 +0100 Message-ID: <20090407181313.GG31824@shareable.org> References: <20090407080046.GQ14571@wotan.suse.de> <20090407102332.GS3204@webber.adilger.int> <20090407152959.GS14571@wotan.suse.de> <20090407174821.GU3204@webber.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Mark Fasheh , linux-fsdevel@vger.kernel.org, Sage Weil , Trond Myklebust To: Andreas Dilger Return-path: Received: from mail2.shareable.org ([80.68.89.115]:36811 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757918AbZDGSNS (ORCPT ); Tue, 7 Apr 2009 14:13:18 -0400 Content-Disposition: inline In-Reply-To: <20090407174821.GU3204@webber.adilger.int> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Andreas Dilger wrote: > > > Instead, as was proposed in the last generation of this thread, > > > there should be > > > AT_GET_{ATIME,MTIME,CTIME,BLOCKS,SIZE,NLINKS,...}, to return the > > > flags that the application actually wants. > > > > Well, I respectfully disagree. In my opinion, this adds unncessary > > complexity to an already targetted case, where only a handful of > > file systems will even care to optimize away a couple of > > fields. In that light, I really think we want simplicity here. > > The difficult part is that the application knows which fields it is going > to use, and the filesystem knows which fields are expensive to fill in, > and by merging multiple fields together you are deciding arbitrarily that > you know better than either. The main users will be common tools like > "ls --color" and "find", and they know exactly which fields are needed, > but they need to do a LOT of stats so making it efficient is worthwhile. I agree with Andreas. The issue isn't "what is efficient and simple (now)", but what makes a good future-compatible interface. > > The good news is that we still have a > > very good amount of space in the flags field. We could always go back if we > > _really_ find the need to micro-optimize to the point of per stat field > > flags. Again though, at this point I don't really think starting out with a > > slew of flags is a good idea. > > Similar to the helper macros for S_IRWXU = (S_IRUSR|S_IWUSR|S_IXUSR) > applications won't necessarily need to specify all flags explicitly. Yes. If it's intended to re-use the fstatat system call for this, the conversion from "no stat field flags" to AT_STAT_ALL should be done in the general fstatat code. fstatat() is for doing stat() or lstat() relative to an open directory. (Anyone else thing the name is stupid - why isn't it statat like openat, etc.?) So how do you do a selective fstat() - attributes of an open file? Don't waste a flag, and just specify AT_SELF as the pathname value to mean return the attributes of the fd argument itself. AT_SELF would be NULL, or perhaps (const char *) -1 to catch application errors. -- Jamie