[Top] [All Lists]

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

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: XFS noikeep remount in 2.6.27-rc1-next-20080730
From: Jasper Bryant-Greene <jasper@xxxxxxxxxxxx>
Date: Wed, 06 Aug 2008 11:44:22 +1200
Cc: Karel Zak <kzak@xxxxxxxxxx>, Christoph Hellwig <hch@xxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, util-linux-ng@xxxxxxxxxxxxxxx
In-reply-to: <20080805233956.GI21635@disturbed>
Organization: Amiton Ltd
References: <1217553598.3860.16.camel@xxxxxxxxxxxxxxxxx> <20080801073033.GF6201@disturbed> <20080801193133.GA838@xxxxxx> <20080805110357.GL21873@xxxxxxxxxxx> <20080805233956.GI21635@disturbed>
Sender: xfs-bounce@xxxxxxxxxxx
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

The filesystem presumably knows what options it was originally mounted

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.


<Prev in Thread] Current Thread [Next in Thread>