Re: [RFC][PATCH 0/4] Enhanced file stat system call

From: One Thousand Gnomes
Date: Thu Nov 17 2016 - 12:53:17 EST

> (2) Lightweight stat (AT_STATX_DONT_SYNC): Ask for just those details of
> interest, and allow a network fs to approximate anything not of
> interest, without going to the server.
> (3) Heavyweight stat (AT_STATX_FORCE_SYNC): Force a network fs to flush
> buffers and go to the server, even if it thinks its cached attributes
> are up to date.

That seems an odd way to do it. Wouldn't it be cleaner and more flexible
to give a timestamp of the oldest time you consider acceptable (and
obviously passing 0 indicates whatever you have)

> (4) Allow the filesystem to indicate what it can/cannot provide: A
> filesystem can now say it doesn't support a standard stat feature if
> that isn't available.
> (5) Make the fields a consistent size on all arches, and make them large.
> (6) Can be extended by using more request flags and using up the padding
> space in the statx struct.
> Note that no lstat() equivalent is required as that can be implemented
> through statx() with atflag == 0. There is also no fstat() equivalent as
> that can be implemented through statx() with filename == NULL and the
> relevant fd passed as dfd.

and dfd + a name gives you fstatat() ? The cover note could be clearer on

Should the fields really be split the way they are for times rather than
a struct for each one so you can write code generically to handle one of
those rather than having to have a 4 way switch statement all the time.

Another attribute that would be nice (but migt need some trivial device
layer tweaking) would be STATX_ATTR_VOLATILE for filesystems that will
probably evaporate on a reboot. That's useful information for tools like
installers and also for sanity checking things like backup paths.

Remote needs to have clear semantics: is ext4fs over nbd 'remote' for
example ?