lkml.org 
[lkml]   [2008]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2008-08-06 01:47    [W:5.013 / U:1.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site