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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
