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
On Fri 03-02-12 16:22:23, Jerome Marchand wrote:
>
> 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.
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
--
Jan Kara <[email protected]>
SUSE Labs, CR
On Mon, Feb 06, 2012 at 11:41:16PM +0100, Jan Kara wrote:
> On Fri 03-02-12 16:22:23, Jerome Marchand wrote:
> >
> > 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.
> 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.
> 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
--
Karel Zak <[email protected]>
http://karelzak.blogspot.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2/6/2012 6:08 PM, Karel Zak wrote:
> On Mon, Feb 06, 2012 at 11:41:16PM +0100, Jan Kara wrote:
>> On Fri 03-02-12 16:22:23, Jerome Marchand wrote:
>>> $ 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
>
> 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-----