Message-ID: <1450404066.6498.70.camel@scientia.net>
Date:	Fri, 18 Dec 2015 03:01:06 +0100
From:	Christoph Anton Mitterer <calestyo@...entia.net>
To:	Qu Wenruo <quwenruo@...fujitsu.com>,
	Eric Sandeen <sandeen@...hat.com>,
	fsdevel <linux-fsdevel@...r.kernel.org>,
	btrfs <linux-btrfs@...r.kernel.org>, kzak@...hat.com
Cc:	linux-ext4@...r.kernel.org, xfs@....sgi.com
Subject: Re: Ideas on unified real-ro mount option across all filesystems

On Fri, 2015-12-18 at 09:29 +0800, Qu Wenruo wrote:
> 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.
> 
> 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.

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:
> ro     Mount the filesystem read-only.
> rw     Mount the filesystem read-write.

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:
> ro     Mount the filehierarchy read-only.


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.
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5313 bytes)

Powered by blists - more mailing lists