fs: filesystem specific options and remount

RFC Jerome Marchand 4 participants 4 messages Feb 3, 2012 – Feb 10, 2012

Subsystems (2)

VFS Util-Linux package

lore

Share & tools

lore

Jerome Marchand

author

2012-02-03 15:22 UTC #0 lore raw

When remounted without option specified, some filesystems keep the options that are already set (e.g. procfs, fat) and some reset them to default (e.g. devpts).
Regarding options that are specified at remount, behavior of filesystems also differ: some apply them (procfs, devpts), some silently disregard them (e.g. fat) and some have a more elaborate behavior (e.g. xfs apparently allows a subset of options to be changed and issues warning if someone tries to change any other option).

Is there any policy regarding what the correct behavior should be? This variety of behaviors tends to confuse mount utility which often does not show the correct option actually set after a remount and most certainly confuses the users as well.

Here is a example of discrepancy between mount (/etc/mtab) and /proc/mounts:

$ grep proc /proc/mounts
/proc /proc proc rw,relatime 0 0
$ mount | grep proc
proc on /proc type proc (rw)

$ mount -o remount,hidepid=2 /proc/
$ grep proc /proc/mounts
/proc /proc proc rw,relatime,hidepid=2 0 0
$ mount | grep proc
proc on /proc type proc (rw,hidepid=2)

$ mount -o remount /proc/
$ grep proc /proc/mounts
/proc /proc proc rw,relatime,hidepid=2 0 0
$ mount | grep proc
proc on /proc type proc (rw)

And here is the discrepancy: mount does not show "hidepid=2" option that is actually still set and enforced. Note that mount also missed the relatime option to begin with.

Regards,
Jerome
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Jan Kara

reviewer

2012-02-06 22:41 UTC #1 lore raw

Quoted 35 lines · Jerome Marchand

When remounted without option specified, some filesystems keep the options that are already set (e.g. procfs, fat) and some reset them to default (e.g. devpts).
Regarding options that are specified at remount, behavior of filesystems also differ: some apply them (procfs, devpts), some silently disregard them (e.g. fat) and some have a more elaborate behavior (e.g. xfs apparently allows a subset of options to be changed and issues warning if someone tries to change any other option).
Is there any policy regarding what the correct behavior should be? This variety of behaviors tends to confuse mount utility which often does not show the correct option actually set after a remount and most certainly confuses the users as well.
Here is a example of discrepancy between mount (/etc/mtab) and /proc/mounts:
$ grep proc /proc/mounts
/proc /proc proc rw,relatime 0 0
$ mount | grep proc
proc on /proc type proc (rw)
$ mount -o remount,hidepid=2 /proc/
$ grep proc /proc/mounts
/proc /proc proc rw,relatime,hidepid=2 0 0
$ mount | grep proc
proc on /proc type proc (rw,hidepid=2)
$ mount -o remount /proc/
$ grep proc /proc/mounts
/proc /proc proc rw,relatime,hidepid=2 0 0
$ mount | grep proc
proc on /proc type proc (rw)

Quoted 3 lines

And here is the discrepancy: mount does not show "hidepid=2" option that is actually still set and enforced. Note that mount also missed the relatime option to begin with.

I don't mind the discrepancy between /etc/mtab and /proc/mounts that much
(/proc/mounts is a fine replacement of /etc/mtab for me) but I agree that handling of mount options on remount is a mess and IMHO it's made even worse by mount(8) adding options from /etc/mtab to mount(2) syscall when -o remount is specified. But realistically I can hardly imagine how to fix all this mess because I'd almost bet userspace depends on the behavior.

Honza

Signature · 2 lines

Jan Kara <[email protected]>
SUSE Labs, CR

Karel Zak

maintainer

2012-02-06 23:08 UTC #2 lore raw

Quoted 36 lines · Jan Kara

Quoted 35 lines · Jerome Marchand
When remounted without option specified, some filesystems keep the options that are already set (e.g. procfs, fat) and some reset them to default (e.g. devpts).
Regarding options that are specified at remount, behavior of filesystems also differ: some apply them (procfs, devpts), some silently disregard them (e.g. fat) and some have a more elaborate behavior (e.g. xfs apparently allows a subset of options to be changed and issues warning if someone tries to change any other option).
Is there any policy regarding what the correct behavior should be? This variety of behaviors tends to confuse mount utility which often does not show the correct option actually set after a remount and most certainly confuses the users as well.
Here is a example of discrepancy between mount (/etc/mtab) and /proc/mounts:
$ grep proc /proc/mounts
/proc /proc proc rw,relatime 0 0
$ mount | grep proc
proc on /proc type proc (rw)
$ mount -o remount,hidepid=2 /proc/
$ grep proc /proc/mounts
/proc /proc proc rw,relatime,hidepid=2 0 0
$ mount | grep proc
proc on /proc type proc (rw,hidepid=2)
$ mount -o remount /proc/
$ grep proc /proc/mounts
/proc /proc proc rw,relatime,hidepid=2 0 0
$ mount | grep proc
proc on /proc type proc (rw)

Quoted 5 lines

Quoted 3 lines
And here is the discrepancy: mount does not show "hidepid=2" option that is actually still set and enforced. Note that mount also missed the relatime option to begin with.
I don't mind the discrepancy between /etc/mtab and /proc/mounts that much
(/proc/mounts is a fine replacement of /etc/mtab for me) but I agree that

Fedora for example does not use /etc/mtab anymore.

Quoted 3 lines

handling of mount options on remount is a mess and IMHO it's made even worse by mount(8) adding options from /etc/mtab to mount(2) syscall when -o remount is specified. But realistically I can hardly imagine how to fix

man mount:

The remount functionality follows the standard way how the mount command works with options from fstab. It means the mount command doesn't read fstab (or mtab) only when a device and dir are fully specified.

mount -o remount,rw /dev/foo /dir

After this call all old mount options are replaced and arbitrary stuff from fstab is ignored, except the loop= option which is internally generated and maintained by the mount command.

mount -o remount,rw /dir

After this call mount reads fstab (or mtab) and merges these options with options from command line ( -o ).

Note that mtab is a fallback solution when the mountpoint is not found in fstab, the mtab is not read by default.

Anyway, libmount allows to specify how use the mount options from mtab and fstab. My plan is to add to mount(8) new command line options to override the current default, probably something like:

--options-mode={ignore,append,prepend,replace}
--options-source={fstab,mtab,none}

so you will have a full control on options for mount(2) syscall.

Karel

Signature · 6 lines

 Karel Zak  <[email protected]>
 http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Phillip Susi

2012-02-10 17:08 UTC #3 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 18 lines · Karel Zak

Quoted 8 lines · Jan Kara
Quoted 7 lines · Jerome Marchand
$ mount -o remount,hidepid=2 /proc/ $ grep proc /proc/mounts 
/proc /proc proc rw,relatime,hidepid=2 0 0 $ mount | grep proc 
proc on /proc type proc (rw,hidepid=2)
$ mount -o remount /proc/ $ grep proc /proc/mounts /proc /proc
proc rw,relatime,hidepid=2 0 0 $ mount | grep proc proc on
/proc type proc (rw)
man mount:
The remount functionality follows the standard way how the mount command works with options from fstab. It means the mount command doesn't read fstab (or mtab) only when a device and dir are fully specified.
mount -o remount,rw /dev/foo /dir

Quoted 8 lines

After this call all old mount options are replaced and arbitrary stuff from fstab is ignored, except the loop= option which is internally generated and maintained by the mount command.
mount -o remount,rw /dir
After this call mount reads fstab (or mtab) and merges these options with options from command line ( -o ).

Based on what you say there, I would guess this means that Jan has proc listed in fstab, so mount tried to reset the mount options to those specified in fstab, and the kernel proc fs left the options unchanged.

It seems to me that the buggy behavior is in the proc fs not clearing the unspecified options. With the classic bitmask mount flags, any that are not set are cleared by the remount, not left at their current status. This is why mount merges the existing flags specified in fstab or mtab with those given on the command line. The behavior should be the same for the string passed mount flags. In other words, mount does its merging and whatever options are passed to the kernel should be enabled, and any that are not should be disabled.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPNU7+AAoJEJrBOlT6nu75uyoH/3TxQOhOFGm2SlC0zwdh4Rld /yotuzWpe27bjPHN9sychVEKeklhV+3kTHhK8DsiYwAHiJfwF2jyRFz9PTFYTmyj 7zLOi+7e7OFkLWxTADb4ihfqXZjEiI8TIK3RmsqAYLglRLPXw5VNgqGjoJx+7gfR YKu9gzRUhjRKFvXoKGskdeGsB+em/PeAgy0qFYI2Et7rHekrX5PZvsjKsw8jqu/O T9zDtbb0HBCub1PouB5leRc6HKuwdipmDrZFS1SV2ymbclMYh6WTkOJA4ngWGQm7 ZCwAqifcTHNvKr/CoAlFZ+m/9b85aAa9gb8vPUWNpZwEv5xpldhvWazGlR8gMkc= =FTgE
-----END PGP SIGNATURE-----