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. > > Karel > > > Man mount: > > remount > > Attempt to remount an already-mounted file system. This is commonly used > to change the mount flags for a file system, especially to make a readonly > file system writeable. It does not change device or mount point. > > 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 gener- > ated 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 ). 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? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
