Re: Attempt at "stat light" implementation

[Jamie Lokier <jamie@shareable.org>]

Oleg Drokin wrote:
>   I have separated stat fields into arbitrary categories based on my idea of how this needs to be done,
>   that could of course be refined in other ways if desired.

Type should get its own category - which is finer grained than mode.
Type (dir, file, link, etc.) is sometimes a lot cheaper than the other
attributes to get, because on some filesystems you don't need to read
the inode to get the type.  See readdir() and d_type.

atime should get its own category, because on at least one filesystem
- Tux3 - atime is kept in a separate part of the storage.  Not reading
the atime if you don't care about it would be good.  Most programs
don't look at atime.

Separate categories for mtime and ctime make sense, although I don't
know of an implementation where it would make a performance difference
at present.

Once you have fine-grained selection of stat fields - it's natural to
ask why not allow _additional_ stat fields in an future-extensible
fashion?  A few things would be handy sometimes, such as inode
generation number, modification generation number (to detect changes
across reboots), and extra flags indicating COW or other properties.

If an "extensible" attribute is not asked for, the kernel must not
fill in that field of the structure as the app may be not have
allocated space for it.  Or it must use a tag-length-value sort of
structure for the result, similar to network CMSGs.

-- Jamie