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