On Thu, 2015-12-17 at 20:51 -0600, Eric Sandeen wrote: > > -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. > > which should leave nothing to the imagination. 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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
