Re: Ideas on unified real-ro mount option across all filesystems

[Eric Sandeen <sandeen@redhat.com>]

<xfs list address fixed>

On 12/16/15 7:41 PM, Qu Wenruo wrote:
> Hi,
> 
> In a recent btrfs patch, it is going to add a mount option to disable
> log replay for btrfs, just like "norecovery" for ext4/xfs.
> 
> But in the discussion on the mount option name and use case, it seems
> better to have an unified and fs independent mount option alias for
> real RO mount
> 
> Reasons:
> 1) Some file system may have already used [no]"recovery" mount option
>    In fact, btrfs has already used "recovery" mount option.
>    Using "norecovery" mount option will be quite confusing for btrfs.

Too bad btrfs picked those semantics when "norecovery" has existed on
other filesystems for quite some time with a different meaning... :(

> 2) More straight forward mount option
>    Currently, to get real RO mount, for ext4/xfs, user must use -o
>    ro,norecovery.
>    Just ro won't ensure real RO, and norecovery can't be used alone.
>    If we have a simple alias, it would be much better for user to use.
>    (it maybe done just in user space mount)

mount(8) simply says:

       ro     Mount the filesystem read-only.

and mount(2) is no more illustrative:

       MS_RDONLY
              Mount file system read-only.

kernel code is no help, either:

#define MS_RDONLY        1      /* Mount read-only */

They say nothing about what, exactly, "read-only" means.  But since at least
the early ext3 days, it means that you cannot write through the filesystem, not
that the filesystem will leave the block device unmodified when it mounts.

I have always interpreted it as simply "no user changes to the filesystem,"
and that is clearly what the vfs does with the flag...

>    Not to mention some fs (yeah, btrfs again) doesn't have "norecovery"
>    but "nologreplay".

well, again, btrfs picked unfortunate semantics, given the precedent set
by other filesystems.

f2fs, ext4, gfs2, nilfs2, and xfs all support "norecovery" - xfs since
forever, ext4 & f2fs since 2009, etc.

> 3) A lot of user even don't now mount ro can still modify device
>    Yes, I didn't know this point until I checked the log replay code of
>    btrfs.
>    Adding such mount option alias may raise some attention of users.

Given that nothing in the documentation implies that the block device itself
must remain unchanged on a read-only mount, I don't see any problem which
needs fixing.  MS_RDONLY rejects user IO; that's all.

If you want to be sure your block device rejects all IO for forensics or
what have you, I'd suggest # blockdev --setro /dev/whatever prior to mount,
and take it out of the filesystem's control.  Or better yet, making an
image and not touching the original.

-Eric

> Any ideas about this?