Messages in this thread | | | Date | Wed, 6 Aug 2008 09:39:57 +1000 | From | Dave Chinner <> | Subject | Re: XFS noikeep remount in 2.6.27-rc1-next-20080730 |
| |
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@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |