Re: [RFC] fs: filesystem specific options and remount

[Jan Kara]

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 <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/