XFS noikeep remount in 2.6.27-rc1-next-20080730

XFS noikeep remount in 2.6.27-rc1-next-20080730

[Jasper Bryant-Greene]

I mount a bunch of XFS filesystems with "noikeep,attr2,noatime", and a
couple also with "ro".

Sometimes I want to remount one of the "ro" ones "rw", to make changes.
This doesn't work anymore in 2.6.27-rc1-next-20080730. The last kernel I
tried which it worked in was 2.6.26 release.

luna ~ # mount -o remount,rw /usr
mount: /usr not mounted already, or bad option

luna ~ # dmesg | tail -n 1
[18702.291344] XFS: mount option "noikeep" not supported for remount

Is this intended behaviour?

-jasper

Re: XFS noikeep remount in 2.6.27-rc1-next-20080730

[Dave Chinner]

[cc'd xfs@oss.sgi.com]

On Fri, Aug 01, 2008 at 01:19:58PM +1200, Jasper Bryant-Greene wrote:
> I mount a bunch of XFS filesystems with "noikeep,attr2,noatime", and a
> couple also with "ro".
> 
> Sometimes I want to remount one of the "ro" ones "rw", to make changes.
> This doesn't work anymore in 2.6.27-rc1-next-20080730. The last kernel I
> tried which it worked in was 2.6.26 release.
> 
> luna ~ # mount -o remount,rw /usr
> mount: /usr not mounted already, or bad option
> 
> luna ~ # dmesg | tail -n 1
> [18702.291344] XFS: mount option "noikeep" not supported for remount
> 
> Is this intended behaviour?

Side effect of this commit:

http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs-2.6.git;a=commit;h=0327f9d799ebb96f67c80dd732b1fdb09527365e

Christoph?

FWIW, noikeep is the default, so you don't need to specify it.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: XFS noikeep remount in 2.6.27-rc1-next-20080730

[Christoph Hellwig]

On Fri, Aug 01, 2008 at 05:30:33PM +1000, Dave Chinner wrote:
> On Fri, Aug 01, 2008 at 01:19:58PM +1200, Jasper Bryant-Greene wrote:
> > I mount a bunch of XFS filesystems with "noikeep,attr2,noatime", and a
> > couple also with "ro".
> > 
> > Sometimes I want to remount one of the "ro" ones "rw", to make changes.
> > This doesn't work anymore in 2.6.27-rc1-next-20080730. The last kernel I
> > tried which it worked in was 2.6.26 release.
> > 
> > luna ~ # mount -o remount,rw /usr
> > mount: /usr not mounted already, or bad option
> > 
> > luna ~ # dmesg | tail -n 1
> > [18702.291344] XFS: mount option "noikeep" not supported for remount
> > 
> > Is this intended behaviour?
> 
> Side effect of this commit:
> 
> http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs-2.6.git;a=commit;h=0327f9d799ebb96f67c80dd732b1fdb09527365e
> 
> Christoph?

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.

Added the util-linux-ng list to shed some light on this, but I suspect
I'll have to change xfs_fs_remount to check if the option passed in
is identical to the one we already have and only reject it when it
changes due to this mount(1) dumbness.

Re: XFS noikeep remount in 2.6.27-rc1-next-20080730

[Karel Zak]

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 ).


-- 
 Karel Zak  <kzak@redhat.com>

Re: XFS noikeep remount in 2.6.27-rc1-next-20080730

[Dave Chinner]

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

Re: XFS noikeep remount in 2.6.27-rc1-next-20080730

[Jasper Bryant-Greene]

On Wed, 2008-08-06 at 09:39 +1000, Dave Chinner wrote:
> 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?

(forgive me, I'm an XFS user, not an XFS developer, so this might be
ignorant)

The filesystem presumably knows what options it was originally mounted
with.

Thus if you take the difference of the set of options you were mounted
with, and the set of options you are now being asked to remount with,
you have the options which are being asked to change.

If changing any of them is unsupported I would expect an error, but in
this case the result of taking the above set difference would be merely
replacing ro with rw, and thus the filesystem is presumably capable of
doing the remount.

-jasper

Re: XFS noikeep remount in 2.6.27-rc1-next-20080730

[Dave Chinner]

On Wed, Aug 06, 2008 at 11:44:22AM +1200, Jasper Bryant-Greene wrote:
> On Wed, 2008-08-06 at 09:39 +1000, Dave Chinner wrote:
> > 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?
> 
> (forgive me, I'm an XFS user, not an XFS developer, so this might be
> ignorant)
> 
> The filesystem presumably knows what options it was originally mounted
> with.
> 
> Thus if you take the difference of the set of options you were mounted
> with, and the set of options you are now being asked to remount with,
> you have the options which are being asked to change.

Sure. But that does not answer my question about what to do with
options that can't be changed. Options can come from more than just
/etc/fstab - they can come from the mount command line itself as
entered by the admin. What do we do if an option is specified that
we do not support in a remount?

The problem is the way mount combines command line options with
options in fstab. I'm not questioning what you did - I'm asking what
the expected behaviour is supposed to be so we can make it behave
the same way as all the other filesystems.

> If changing any of them is unsupported I would expect an error, but in
> this case the result of taking the above set difference would be merely
> replacing ro with rw, and thus the filesystem is presumably capable of
> doing the remount.

Use the full device/directory syntax for the remount command and it
will do just that. The command you issued was not a "pure" remount,rw,
it was silently changed by mount....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: XFS noikeep remount in 2.6.27-rc1-next-20080730

[gus3]

--- On Tue, 8/5/08, Dave Chinner <david@fromorbit.com> wrote:

> 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?

How about a middle ground: ignore, but not silently? Report an error, or send it to the syslog, or both, but ultimately ignore unchangeable options, change what can be changed, and give the user/admin as much as possible.

This can be particularly pertinent for XFS root. If it's mounted RO at first, it may (will?) need to become RW at some later point. Failing the remount could result in a system that requires a rescue CD (or lots of headaches for remote administration).

Re: XFS noikeep remount in 2.6.27-rc1-next-20080730

[Jasper Bryant-Greene]

On Tue, 2008-08-05 at 21:33 -0700, gus3 wrote:
> --- On Tue, 8/5/08, Dave Chinner <david@fromorbit.com> wrote:
> 
> > 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?
> 
> How about a middle ground: ignore, but not silently? Report an error, or send it to the syslog, or both, but ultimately ignore unchangeable options, change what can be changed, and give the user/admin as much as possible.

I think the idea is to behave the same as other FS do, not to innovate.

> This can be particularly pertinent for XFS root. If it's mounted RO at first, it may (will?) need to become RW at some later point. Failing the remount could result in a system that requires a rescue CD (or lots of headaches for remote administration).

FWIW, your root filesystem does not need to be rw. I keep mine ro nearly
all the time on my laptop, only mounting rw if I need to install
software that puts files outside /usr or if I need to modify a config
file in /etc.

-jasper