Ideas on unified real-ro mount option across all filesystems

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.

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)

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

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.

Any ideas about this?

Thanks,
Qu

And here is the existing discussion in btrfs mail list, just for reference:

http://thread.gmane.org/gmane.comp.file-systems.btrfs/51098

Thanks,
Qu

Qu Wenruo wrote on 2015/12/17 09:41 +0800:

<xfs list address fixed>

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

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

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.

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

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

That ("-o ro means no user changes") has always been my understanding too. You /want/ the FS to replay the journal on an RO mount so that regular FS operation picks up the committed transactions.

--D

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

That's my understanding, too, but after some point in time. It was explained to me some years ago after I found out that a disk image mounted read only was modified. The trick was to make the image '-w'.

I have the vague feeling that once I found a problem when a mount failed or crashed when the image was ro.

Just a user view on this :-)

- --
Cheers / Saludos,

		Carlos E. R.
		(from 13.1 x86_64 "Bottle" at Telcontar)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlZyyBsACgkQtTMYHG2NR9VDYACfRd6Zzd60JzX6LoW1F2K4fSai OJAAoJXgLlcrlFZy1U2MzCBaQ4cz0EmP
=s8oq
-----END PGP SIGNATURE-----

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

That's my understanding, too, but after some point in time, not initially. It was explained to me some years ago after I found out that a disk image mounted read only was modified. The trick was to make the image '-w'.

I also have the vague feeling that once (years ago) I found a problem when a mount failed or crashed when the image was ro.

Just a user view on this :-)

- --
Cheers / Saludos,

		Carlos E. R.
		(from 13.1 x86_64 "Bottle" at Telcontar)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlZyzYkACgkQtTMYHG2NR9VDNwCfehM5NHMAgZuuzLf99kKulLKI AkAAnjt4mZngHZdH5v60T+P6tnnFzUiO
=Pw+f
-----END PGP SIGNATURE-----

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

Yep,

I agree, it's FS specific business to interpret the 'ro'.

And it's already enough complicated, we have three levels of "read-only":

- read-only device (blockdev --setro ioctl)
- read-only filesystem (mount -o ro)
- read-only VFS node (mount -o remount,ro,bind /src /dst)

and for example in /proc/self/mountinfo we distinguish between FS "ro" and VFS "ro" flag:

# grep test /proc/self/mountinfo
185 59 8:5 / /mnt/test ro,relatime shared:32 - ext4 /dev/sda5 rw,data=ordered
                       ^^                                     ^^

BTW, util-linux 2.27 mount(8) man page:

-r, --read-only
Mount the filesystem read-only. A synonym is -o ro.

Note that, depending on the filesystem type, state and kernel behavior, the system may still write to the device. For example, ext3 and ext4 will replay the journal if the filesystem is dirty. To prevent this kind of write access, you may want to mount an ext3 or ext4 filesystem with the ro,noload mount options or set the block device itself to read-only mode, see the blockdev(8) command.

(maybe we need to copy this note to "ro" description too and add hint about btrfs too :-)

Karel

 Karel Zak  <[email protected]>
 http://karelzak.blogspot.com

Eric Sandeen wrote on 2015/12/16 21:15 -0600:

I understand it's btrfs' fault.
Considering how many filesystems are already using "norecovery", it is almost a standard.

Not sure if it's possible to change the "recovery" mount option to other name for btrfs, but it seems using "norecovery" would be the best solution.

And thanks for the info provided by Karel, it's clear that at least mount(8) itself already has explain on what ro will do and what it won't do.

Thanks,
Qu

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

I wouldn't really agree, here. At least not from the non-developer side (and one should hope filesystems and their manpages aren't only made for fs-devlopers).

The manpage says:

IMHO, that leaves absolutely unclear, what this actually means, especially given that most end-users will probably consider the filesystem and its device being basically "the same".

Especially, "the filesystem read-only", does not imply at all, whether this property means "anything accessed via the filesystem", where the filesystem would be the interface to the data, so that would mean, that users cannot change files, their properties, permissions, xattrs, acls, *time, and of course contents of any files,... nor whether it means "the filesystem as the full number of bytes that comprise the filesystem", which would include anything that is hidden from the user (like journals etc.).

In fact, though I know it's not the case in practise, alone from the wording above, which uses "filesystem", I'd rather tend to says that this includes any hidden structures and that "ro" in fact means, that the filesystem driver doesn't change the filesystem (in other words, no writes to the device, from the fs).

From what the mount option "ro" actually means, I'd rather expect that the manpage should read:

I do not dispute, that it makes sense to have a soft "ro" which just means that the exported file-hierarchy is read-only.
But similarly it makes sense to have a "hard ro", which means, that the filesystem doesn't do any writes. That implies of course the soft ro, but also means, no journal replays, no mount time updates, no rebuilds in case of multi-device setups.

This may be helpful in several situations (when doing device backups from mounted filesystems, in any disaster recovery or forensic situation).
Now people may argue, that there's blockdev --setro, which is true of course,... but a) I'd now quite some people whom I'd consider not to be totally stupid end-users and who'd, by the above documentation of "ro" assume that there are no changes on the block device, and b) it may be helpful for the filesystem driver itself, to not even try to do writes (and then error out), but from the beginning be in a I-don't-wanna- write-mode.

As it has been discussed by some people on linux-btrfs, norecovery, no load, nologreplay or whatever options there are, which *currently* make certain fs types behave like that, i.e. make them "hard ro", are not that suited, neither from their name, nor from their semantics. "nologreplay" may be the option that *right now* makes btrfs not writing to the device, but in 5 years other features may have been introduced which would also people require to add the mountoption "nofoobarmagic".
For normal users, not following each commit of development (and who certainly don't read the manpage every day again, not to talk that these often are ambiguous or outdated), a option which is defined to imply everything that's necessary to make the filesystem not touch its underlying devices seems quite reasonable.

I myself had proposed the name "nodevwrites" (or something like that) over at linux-btrfs, since that seems the semantics that were desired (plus it's, AFAICS, not used already).
It could be commonly "reserved" for that purpose, and each filesystem type that wants to support it could make it imply everything needed to make mounts of that filesystem truly read-only in the sense of "do not change a single bit on the device".
Doesn't seem to be a too invasive change, and seems worth it.

And obviously, such a option that means "hard ro", should per definition include noatime (just in the case there are filesystems left, which would update the atimes even when mounted "ro").

Oh and I'd actually think, that changing the mount(8) manpage to use "file-hierarchy" instead of "filesystem" and perhaps loosing a short sentence what this actually means (something like "no file data changes, no permissions, owners, acls, xattrs, [a|m|c|*]time changes - but especially any other fs internal changes are still allowed").

Cheers,
Chris.

<lots of words snipped>

Karel pointed out that recent mount(8) says:

which should leave nothing to the imagination.

-Eric

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

hmm apparently Debian sid's mount(8) is a bit outdated, but anyway, this just means that the behaviour of "ro" is not properly (end-user- friendly) documented. :-)

I still see basically the following left:
a) Could filesystems benefit from knowing that they shouldn't write to the device (e.g. by spitting out less errors or that like)?
b) Or does each filesystem auto-detect, that the blockdev is "ro" and does handle accordingly?
c) Are there other cases left, where using blockdev --setro may be a worse solution to having a dedicated mount option for "hard ro"?

If only (b) would apply, then the state as is seems fine, and pointing people to blockdev --setro would be enough.
But would (b) work in case of multi-dev fs, where e.g. some can be ro (perhaps seed devices) while others can be rw?

If (a) would apply, then it would IMHO still make sense to have dedicated "hard ro" mountoption. The above manpage snipped would already show that it names "noload", but this is only for ext* and as I've said before, manpages which can easily be out of date, may not list all options that are required by then, especially not for each fs.

If (c) would apply, then I think for the same reasons, having a dedicated mount option would be beneficial.

Examples I can think of:
btrfs with multidevices.
Imagine you have a big box with some 100 disks, and multiple multi- device btrfs filesystems on these.
One goes bad, and you want to start with recovery or forensics, but that fs comprised of 34 devices (thus it's not easy to do this on some other node).
Do we really want to let people start to call --setro on these 34 devices (maybe some of them are multipath) and perhaps even accidentally setting the wrong device ro, thereby causing damage to live filesystem?
It would be much simpler if one had a mount option, wouldn't it.

Well just some thoughts, though.

Cheers,
Chris.

Am Fri, 18 Dec 2015 03:01:06 +0100
schrieb Christoph Anton Mitterer <[email protected]>:

That means: the filesystem... Not the block device...

Sorry, it's kinda nitpicking. But actually, the file system IS
read-only: You cannot modify files from user's view.

What you actually want is not modifying the underlying storage which is the block device and includes stuff like meta and journal data (which is only indirectly visible to users at best).

You can argue that man pages are not particularly end-user friendly. But for an admin this makes sense without being an fs developer.

Regards,
Kai

Replies to list-only preferred.


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

No, that means: That particular instantiation of the VFS layer to access the filesystem.
Not the filesystem (the filesystem is the data and metadata on disk), not the block device (which is an abstraction used as a container for the filesystem).

From a non technical view point, yes, that is correct; until you have undetected corruption in the journal or log or whatever other structure is used for consistency, at which point it isn't read-only because the filesystem just changed by virtue of you mounting it (and even without that type of corruption, stuff gets changed on a 'read-only' mount regardless in many filesystems, many of them track when the filesystem was last mounted, how many times it's been mounted, and other similar things).

No, the metadata and journal are a integral part of the filesystem itself. Without those, there is no filesystem. That and the metadata _is_ directly visible to the user, in the form of directory structure, stat(), output from lsattr, and even stuff like FIEMAP and filefrag.

The filesystem _is_ the data and metadata on disk, as such, the filesystem being read-only means that none of that data or metadata should change.

That really depends. I'm not a FS developer, but I still expect when I see 'read-only' that it means the same as 'immutable for everything managed by that particular object that has been made read-only, for all access methods through that object'. And while I bet most administrators wouldn't use quite the same terminology, I would be willing to bet that many of them have essentially the same expectation unless specifically told otherwise on a case-by-case basis.

What we do for the petitboot bootloader in POWER and OpenPower firmware (a linux+initramfs that does kexec to boot) is that we use device mapper to make a snapshot in memory where we run recovery (for some filesystems, notably XFS is different due to journal not being endian safe). We also have to have an option *not* to do that, just in case there's a bug in journal replay... and we're lucky in the fact that we probably do have enough memory to complete replay, this solution could be completely impossible on lower memory machines.

As such, I believe we're the only bit of firmware/bootloader ever that has correctly parsed a journalling filesystem.

Stewart Smith

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

Which means the boot loader is going to break horribly when we change the on-disk format and feature flags the boot loader doesn't understand get set in the root filesystem. Then the bootloader will refuse to mount the filesystem and the system won't boot anymore...

IOWs, developers and users can't make a root XFS filesystem with a new/experimental feature on POWER/OpenPower machines because the bootloader will refuse to mount it regardless of the clean/dirty state of the journal....

Nope. The Irix bootloader (sash) could do this 20 years ago - there are even feature mask bits reserved specifically for SASH in the XFS superblock. However, seeing as the bootloader was always upgraded during the install of each new Irix release, the bootloader was always up-to-date with the on-disk features the kernel supported and so there was never a problem with mismatched feature support.

However, Linux users can upgrade or change the kernel at any time independently of the bootloader, so it's pretty much guaranteed that mismatched bootloader/kernel filesystem capabilities will cause users problems at some point in the not-too-distant future.

Cheers,

Dave.

Dave Chinner
[email protected]