On Tue, 2022-08-16 at 14:55 +0100, David Howells wrote: > Christian Brauner <brauner@xxxxxxxxxx> wrote: > > > > +#define STATX_CHANGE_ATTR 0x00002000U /* Want/got stx_change_attr */ > > > > I'm a bit worried that STATX_CHANGE_ATTR isn't a good name for the flag > > and field. Or I fail to understand what exact information this will > > expose and how userspace will consume it. > > To me the naming gives the impression that some set of generic > > attributes have changed but given that statx is about querying file > > attributes this becomes confusing. > > > > Wouldn't it make more sense this time to expose it as what it is and > > call this STATX_INO_VERSION and __u64 stx_ino_version? > > I'm not sure that STATX_INO_VERSION is better that might get confused with the > version number that's used to uniquify inode slots (ie. deal with inode number > reuse). > > The problem is that we need fsinfo() or similar to qualify what this means. > On some filesystems, it's only changed when the data content changes, but on > others it may get changed when, say, xattrs get changed; further, on some > filesystems it might be monotonically incremented, but on others it's just > supposed to be different between two consecutive changes (nfs, IIRC). > I think we'll just have to ensure that before we expose this for any filesystem that it conforms to some minimum standards. i.e.: it must change if there are data or metadata changes to the inode, modulo atime changes due to reads on regular files or readdir on dirs. The local filesystems, ceph and NFS should all be fine. I guess that just leaves AFS. If it can't guarantee that, then we might want to avoid exposing the counter for it. -- Jeff Layton <jlayton@xxxxxxxxxx>
