Re: [PATCH] fs: i_version mntopt gets visible through /proc/mounts

[Eric Sandeen <sandeen@sandeen.net>]

On 6/17/20 12:24 PM, Darrick J. Wong wrote:
> On Wed, Jun 17, 2020 at 12:14:28PM -0500, Eric Sandeen wrote:
>>
>>
>> On 6/17/20 10:58 AM, J. Bruce Fields wrote:
>>> On Wed, Jun 17, 2020 at 01:03:14AM -0700, Christoph Hellwig wrote:
>>>> On Tue, Jun 16, 2020 at 04:21:23PM -0400, Masayoshi Mizuma wrote:
>>>>> From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
>>>>>
>>>>> /proc/mounts doesn't show 'i_version' even if iversion
>>>>> mount option is set to XFS.
>>>>>
>>>>> iversion mount option is a VFS option, not ext4 specific option.
>>>>> Move the handler to show_sb_opts() so that /proc/mounts can show
>>>>> 'i_version' on not only ext4 but also the other filesystem.
>>>>
>>>> SB_I_VERSION is a kernel internal flag.  XFS doesn't have an i_version
>>>> mount option.
>>>
>>> It probably *should* be a kernel internal flag, but it seems to work as
>>> a mount option too.
>>
>> Not on XFS AFAICT:
>>
>> [600280.685810] xfs: Unknown parameter 'i_version'
> 
> Yeah, because the mount option is 'iversion', not 'i_version'.  Even if

unless you're ext4:

{Opt_i_version, "i_version"},

ok "iversion" is what mount(8) takes and translates into MS_I_VERSION (thanks Darrick)

# strace -vv -emount mount -oloop,iversion fsfile mnt
mount("/dev/loop0", "/tmp/mnt", "xfs", MS_I_VERSION, NULL) = 0

FWIW, mount actually seems to pass what it finds in /proc/mounts back in on remount for ext4:

# strace -vv -emount mount -o remount mnt
mount("/dev/loop0", "/tmp/mnt", 0x55bfcbdca150, MS_REMOUNT|MS_RELATIME, "seclabel,i_version,data=ordered") = 0

but it still looks unhandled on remount.  Perhaps if /proc/mounts exposed
"iversion" (not "i_version") then mount -o remount would DTRT.

-Eric

> you were going to expose the flag state in /proc/mounts, the text string
> should match the mount option.
> 
>> so we can't be exporting "mount options" for xfs that aren't actually
>> going to be accepted by the filesystem.
>>
>>> By coincidence I've just been looking at a bug report showing that
>>> i_version support is getting accidentally turned off on XFS whenever
>>> userspace does a read-write remount.
>>>
>>> Is there someplace in the xfs mount code where it should be throwing out
>>> SB_I_VERSION?
>>
>> <cc xfs list>
>>
>> XFS doesn't manipulate that flag on remount.  We just turn it on by default
>> for modern filesystem formats:
>>
>>         /* version 5 superblocks support inode version counters. */
>>         if (XFS_SB_VERSION_NUM(&mp->m_sb) == XFS_SB_VERSION_5)
>>                 sb->s_flags |= SB_I_VERSION;
>>
>> Also, this behavior doesn't seem unique to xfs:
>>
>> # mount -o loop,i_version fsfile test_iversion
>> # grep test_iversion /proc/mounts
>> /dev/loop4 /tmp/test_iversion ext4 rw,seclabel,relatime,i_version 0 0
>> # mount -o remount test_iversion
>> # grep test_iversion /proc/mounts
>> /dev/loop4 /tmp/test_iversion ext4 rw,seclabel,relatime 0 0
>> # uname -a
>> Linux <hostname> 5.7.0-rc4+ #7 SMP Wed Jun 10 14:01:34 EDT 2020 x86_64 x86_64 x86_64 GNU/Linux
> 
> Probably because do_mount clears it and I guess xfs don't re-enable
> it in any of their remount functions...