On Tue, 2023-04-11 at 11:49 +0200, Christian Brauner wrote: > > > > > > Afaict, filesystems that persist i_version to disk automatically raise > > > SB_I_VERSION. I would guess that it be considered a bug if a filesystem > > > would persist i_version to disk and not raise SB_I_VERSION. If so IMA > > > should probably be made to check for IS_I_VERSION() and it will probably > > > get that by switching to vfs_getattr_nosec(). > > > > Not quite. SB_I_VERSION tells the vfs that the filesystem wants the > > kernel to manage the increment of the i_version for it. The filesystem > > is still responsible for persisting that value to disk (if appropriate). > > Yes, sure it's the filesystems responsibility to persist it to disk or > not. What I tried to ask was that when a filesystem does persist > i_version to disk then would it be legal to mount it without > SB_I_VERSION (because ext2/ext3 did use to have that mount option)? If > it would then the filesystem would probably need to take care to leave > the i_version field in struct inode uninitialized to avoid confusion or > would that just work? (Mere curiosity, don't feel obligated to go into > detail here. I don't want to hog your time.) > In modern kernels, not setting SB_I_VERSION would mainly have the effect of stopping increments of i_version field on write. It would also mean that the STATX_CHANGE_COOKIE is not automatically reported via getattr. You probably wouldn't want to mount the fs without SB_I_VERSION set. The missing increments could trick an observer into believing that nothing had changed in the file across mounts when it actually had. -- Jeff Layton <jlayton@xxxxxxxxxx>
