On Wed, Jun 17, 2020 at 09:30:26PM -0400, Masayoshi Mizuma wrote: > On Wed, Jun 17, 2020 at 02:45:07PM -0400, J. Bruce Fields wrote: > > On Wed, Jun 17, 2020 at 01:28:11PM -0500, Eric Sandeen wrote: > > > but mount(8) has already exposed this interface: > > > > > > iversion > > > Every time the inode is modified, the i_version field will be incremented. > > > > > > noiversion > > > Do not increment the i_version inode field. > > > > > > so now what? > > > > It's not like anyone's actually depending on i_version *not* being > > incremented. (Can you even observe it from userspace other than over > > NFS?) > > > > So, just silently turn on the "iversion" behavior and ignore noiversion, > > and I doubt you're going to break any real application. > > I suppose it's probably good to remain the options for user compatibility, > however, it seems that iversion and noiversiont are useful for > only ext4. > How about moving iversion and noiversion description on mount(8) > to ext4 specific option? > > And fixing the remount issue for XFS (maybe btrfs has the same > issue as well)? > For XFS like as: > > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c > index 379cbff438bc..2ddd634cfb0b 100644 > --- a/fs/xfs/xfs_super.c > +++ b/fs/xfs/xfs_super.c > @@ -1748,6 +1748,9 @@ xfs_fc_reconfigure( > return error; > } > > + if (XFS_SB_VERSION_NUM(&mp->m_sb) == XFS_SB_VERSION_5) > + mp->m_super->s_flags |= SB_I_VERSION; > + I wonder, does this have to be done at the top of this function because the vfs already removed S_I_VERSION from s_flags? --D > return 0; > } > > Thanks, > Masa
