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.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
