Re: Ideas on unified real-ro mount option across all filesystems

[Christoph Anton Mitterer <calestyo@scientia.net>]

[-- Attachment #1: Type: text/plain, Size: 2719 bytes --]

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 #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]