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.
smime.p7s
Description: S/MIME cryptographic signature
|