From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: Attempt at "stat light" implementation Date: Tue, 07 Apr 2009 03:23:40 -0700 Message-ID: <20090407102340.GT3204@webber.adilger.int> References: <20090407062356.GA1336463@fiona.linuxhacker.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Cc: linux-fsdevel@vger.kernel.org To: Oleg Drokin Return-path: Received: from sca-es-mail-1.Sun.COM ([192.18.43.132]:33290 "EHLO sca-es-mail-1.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751792AbZDGKXo (ORCPT ); Tue, 7 Apr 2009 06:23:44 -0400 Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n37ANg3l000844 for ; Tue, 7 Apr 2009 03:23:42 -0700 (PDT) Content-disposition: inline Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHQ008007H3EM00@fe-sfbay-10.sun.com> for linux-fsdevel@vger.kernel.org; Tue, 07 Apr 2009 03:23:42 -0700 (PDT) In-reply-to: <20090407062356.GA1336463@fiona.linuxhacker.ru> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Apr 07, 2009 10:23 +0400, Oleg Drokin wrote: > Also perhaps the ->getattr just needs a prototype change to accept the > flags argument and if the FS cares about it - to use it, but I did not > want to do this huge patch touching every FS right now if only to save > my time should this approach to be determined as undesirable for one > reason or another, so for now I add a ->getattr_light You mean like open(path, flags, mode), where the @mode argument is optional? I think that has caused a lot of headaches in the past. > +/* Bits to define what fields the "stat light" syscall must fill in > + * struct stat, should not intersect with above AT_* bits */ > +#define STAT_NLINK 0x01000 /* nlink */ > +#define STAT_TIMES 0x02000 /* atime, mtime, ctime */ > +#define STAT_SIZE 0x04000 /* File size and blocks */ > +#define STAT_ACCESS 0x08000 /* mode, user, group */ > +#define STAT_EVERYTHING 0x0f000 /* Just a normal stat */ The very most common fields that will need to be returned are type and mode, because "ls --color" (the default) does this. These should get their own flag at minimum, and should definitely be separate from uid/gid. One issue I recall with uid/gid is that in some environments the UID/GID may be remapped for remote UID mapping (maybe with an LDAP or Kerberos query for each one), and forcing the filesystem to do this when "ls" is just going to throw them away is pointless. Even the inode numbers cost a non-zero amount of work in some filesystems that have to expose a persistent 32-bit mapping. I'd prefer to have more fine grained control than this, since the application knows what it wants, and it is impossible to predicy what the "slow" operation is for a given filesystem/workload. In the end it DOES seem that fstatat(2) is a sufficient interface for this: int fstatat(int dirfd, const char *pathname, struct stat *buf, int flags); since it is working on the directory and passing in the filenames for each file. There is even a AT_SYMLINK_NOFOLLOW to avoid the need to have a separate "l" version. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.