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

[One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>]

>  (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
this.

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 ?

Alan