Hello!
On Apr 7, 2009, at 6:23 AM, Andreas Dilger wrote:
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.
No, I mean, it would not be optional, just not every filesystem would
care.
Say for a most local filesystems it is supposedly equal amount of work
to get just some inode field as it is to get entire struct stat, since
they need to just read the inode from disk (if not cached) anyway.
+/* 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.
Sure, we can do this. We can even have a flag per every field in
struct stat + more generic masks for commonly requested together
fields.
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.
Sure.
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.
I thought about it, but unless we would allow userspace to pass in
the magic AT_FDCWD, they would still would need to open something
even if only once per run (and probably once per dir, to avoid
extra lookup overhead), and that is probably not very desirable.
Bye,
Oleg
--
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
