On Tue, Aug 05, 2008 at 01:03:57PM +0200, Karel Zak wrote:
> On Fri, Aug 01, 2008 at 09:31:33PM +0200, Christoph Hellwig wrote:
> > I'ts most likely a fallout, but I wonder why. To get this behaviour
> > moutn would have to add all the options it finds in /proc/self/mounts
> > to the command line.
> mount(8) does not read and use /proc/self/mounts at all.
> Man mount:
> Attempt to remount an already-mounted file system. This is commonly
> to change the mount flags for a file system, especially to make a
> file system writeable. It does not change device or mount point.
> The remount functionality follows the standard way how the mount
> works with options from fstab. It means the mount command doesnât
> 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
> from fstab is ignored, except the loop= option which is internally
> ated and maintained by the mount command.
> mount -o remount,rw /dir
> After this call mount reads fstab (or mtab) and merges these options
> options from command line ( -o ).
So, given the command at issue was:
luna ~ # mount -o remount,rw /usr
We're seeing the second case where mount is merging all the options in
/etc/fstab into the options passed into the remount command. How is
the filesystem expected to behave in these difference cases? The
first simply changes the ro/rw status, the second potentially
asks for the filesystem to change a bunch of other mount options
as well, which it may not be able to do.
So what is the correct behaviour? Should the filesystem *silently
ignore* unchangable options in the remount command, or should it
fail the remount and warn the user that certain options are not
allowed in remount?