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

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

[Eric Sandeen]

<xfs list address fixed>

On 12/16/15 7:41 PM, Qu Wenruo wrote:
> Hi,
> 
> In a recent btrfs patch, it is going to add a mount option to disable
> log replay for btrfs, just like "norecovery" for ext4/xfs.
> 
> But in the discussion on the mount option name and use case, it seems
> better to have an unified and fs independent mount option alias for
> real RO mount
> 
> Reasons:
> 1) Some file system may have already used [no]"recovery" mount option
>    In fact, btrfs has already used "recovery" mount option.
>    Using "norecovery" mount option will be quite confusing for btrfs.

Too bad btrfs picked those semantics when "norecovery" has existed on
other filesystems for quite some time with a different meaning... :(

> 2) More straight forward mount option
>    Currently, to get real RO mount, for ext4/xfs, user must use -o
>    ro,norecovery.
>    Just ro won't ensure real RO, and norecovery can't be used alone.
>    If we have a simple alias, it would be much better for user to use.
>    (it maybe done just in user space mount)

mount(8) simply says:

       ro     Mount the filesystem read-only.

and mount(2) is no more illustrative:

       MS_RDONLY
              Mount file system read-only.

kernel code is no help, either:

#define MS_RDONLY        1      /* Mount read-only */

They say nothing about what, exactly, "read-only" means.  But since at least
the early ext3 days, it means that you cannot write through the filesystem, not
that the filesystem will leave the block device unmodified when it mounts.

I have always interpreted it as simply "no user changes to the filesystem,"
and that is clearly what the vfs does with the flag...

>    Not to mention some fs (yeah, btrfs again) doesn't have "norecovery"
>    but "nologreplay".

well, again, btrfs picked unfortunate semantics, given the precedent set
by other filesystems.

f2fs, ext4, gfs2, nilfs2, and xfs all support "norecovery" - xfs since
forever, ext4 & f2fs since 2009, etc.

> 3) A lot of user even don't now mount ro can still modify device
>    Yes, I didn't know this point until I checked the log replay code of
>    btrfs.
>    Adding such mount option alias may raise some attention of users.

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.

If you want to be sure your block device rejects all IO for forensics or
what have you, I'd suggest # blockdev --setro /dev/whatever prior to mount,
and take it out of the filesystem's control.  Or better yet, making an
image and not touching the original.

-Eric

> Any ideas about this?



_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Darrick J. Wong]

On Wed, Dec 16, 2015 at 09:15:59PM -0600, Eric Sandeen wrote:
> <xfs list address fixed>
> 
> On 12/16/15 7:41 PM, Qu Wenruo wrote:
> > Hi,
> > 
> > In a recent btrfs patch, it is going to add a mount option to disable
> > log replay for btrfs, just like "norecovery" for ext4/xfs.
> > 
> > But in the discussion on the mount option name and use case, it seems
> > better to have an unified and fs independent mount option alias for
> > real RO mount
> > 
> > Reasons:
> > 1) Some file system may have already used [no]"recovery" mount option
> >    In fact, btrfs has already used "recovery" mount option.
> >    Using "norecovery" mount option will be quite confusing for btrfs.
> 
> Too bad btrfs picked those semantics when "norecovery" has existed on
> other filesystems for quite some time with a different meaning... :(
> 
> > 2) More straight forward mount option
> >    Currently, to get real RO mount, for ext4/xfs, user must use -o
> >    ro,norecovery.
> >    Just ro won't ensure real RO, and norecovery can't be used alone.
> >    If we have a simple alias, it would be much better for user to use.
> >    (it maybe done just in user space mount)
> 
> mount(8) simply says:
> 
>        ro     Mount the filesystem read-only.
> 
> and mount(2) is no more illustrative:
> 
>        MS_RDONLY
>               Mount file system read-only.
> 
> kernel code is no help, either:
> 
> #define MS_RDONLY        1      /* Mount read-only */
> 
> They say nothing about what, exactly, "read-only" means.  But since at least
> the early ext3 days, it means that you cannot write through the filesystem, not
> that the filesystem will leave the block device unmodified when it mounts.
> 
> I have always interpreted it as simply "no user changes to the filesystem,"
> and that is clearly what the vfs does with the flag...

That ("-o ro means no user changes") has always been my understanding too.  You
/want/ the FS to replay the journal on an RO mount so that regular FS operation
picks up the committed transactions.

--D

> 
> >    Not to mention some fs (yeah, btrfs again) doesn't have "norecovery"
> >    but "nologreplay".
> 
> well, again, btrfs picked unfortunate semantics, given the precedent set
> by other filesystems.
> 
> f2fs, ext4, gfs2, nilfs2, and xfs all support "norecovery" - xfs since
> forever, ext4 & f2fs since 2009, etc.
> 
> > 3) A lot of user even don't now mount ro can still modify device
> >    Yes, I didn't know this point until I checked the log replay code of
> >    btrfs.
> >    Adding such mount option alias may raise some attention of users.
> 
> 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.
> 
> If you want to be sure your block device rejects all IO for forensics or
> what have you, I'd suggest # blockdev --setro /dev/whatever prior to mount,
> and take it out of the filesystem's control.  Or better yet, making an
> image and not touching the original.
> 
> -Eric
> 
> > Any ideas about this?
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Carlos E. R.]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2015-12-17 04:26, Darrick J. Wong wrote:
> On Wed, Dec 16, 2015 at 09:15:59PM -0600, Eric Sandeen wrote:


>> I have always interpreted it as simply "no user changes to the
>> filesystem," and that is clearly what the vfs does with the
>> flag...
> 
> That ("-o ro means no user changes") has always been my
> understanding too.  You /want/ the FS to replay the journal on an
> RO mount so that regular FS operation picks up the committed
> transactions.

That's my understanding, too, but after some point in time. It was
explained to me some years ago after I found out that a disk image
mounted read only was modified. The trick was to make the image '-w'.

I have the vague feeling that once I found a problem when a mount
failed or crashed when the image was ro.


Just a user view on this :-)

- -- 
Cheers / Saludos,

		Carlos E. R.
		(from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlZyyBsACgkQtTMYHG2NR9VDYACfRd6Zzd60JzX6LoW1F2K4fSai
OJAAoJXgLlcrlFZy1U2MzCBaQ4cz0EmP
=s8oq
-----END PGP SIGNATURE-----

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Carlos E. R.]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2015-12-17 04:26, Darrick J. Wong wrote:
> On Wed, Dec 16, 2015 at 09:15:59PM -0600, Eric Sandeen wrote:

>> I have always interpreted it as simply "no user changes to the
>> filesystem," and that is clearly what the vfs does with the
>> flag...
> 
> That ("-o ro means no user changes") has always been my
> understanding too.  You /want/ the FS to replay the journal on an
> RO mount so that regular FS operation picks up the committed
> transactions.
> 
> --D

That's my understanding, too, but after some point in time, not
initially. It was explained to me some years ago after I found out
that a disk image mounted read only was modified. The trick was to
make the image '-w'.

I also have the vague feeling that once (years ago) I found a problem
when a mount failed or crashed when the image was ro.


Just a user view on this :-)

- -- 
Cheers / Saludos,

		Carlos E. R.
		(from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlZyzYkACgkQtTMYHG2NR9VDNwCfehM5NHMAgZuuzLf99kKulLKI
AkAAnjt4mZngHZdH5v60T+P6tnnFzUiO
=Pw+f
-----END PGP SIGNATURE-----

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Karel Zak]

On Wed, Dec 16, 2015 at 09:15:59PM -0600, Eric Sandeen wrote:
> I have always interpreted it as simply "no user changes to the filesystem,"
> and that is clearly what the vfs does with the flag...

Yep,

> 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.

I agree, it's FS specific business to interpret the 'ro'.

And it's already enough complicated, we have three levels of "read-only":

 - read-only device (blockdev --setro ioctl)
 - read-only filesystem (mount -o ro)
 - read-only VFS node (mount -o remount,ro,bind /src /dst)

and for example in /proc/self/mountinfo we distinguish between FS "ro"
and VFS "ro" flag:

# grep test /proc/self/mountinfo
185 59 8:5 / /mnt/test ro,relatime shared:32 - ext4 /dev/sda5 rw,data=ordered
                       ^^                                     ^^


BTW, util-linux 2.27 mount(8) man page:

   -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.


 (maybe we need to copy this note to "ro" description too and add hint
 about btrfs too :-)

     Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Qu Wenruo]

Eric Sandeen wrote on 2015/12/16 21:15 -0600:
> <xfs list address fixed>
>
> On 12/16/15 7:41 PM, Qu Wenruo wrote:
>> Hi,
>>
>> In a recent btrfs patch, it is going to add a mount option to disable
>> log replay for btrfs, just like "norecovery" for ext4/xfs.
>>
>> But in the discussion on the mount option name and use case, it seems
>> better to have an unified and fs independent mount option alias for
>> real RO mount
>>
>> Reasons:
>> 1) Some file system may have already used [no]"recovery" mount option
>>     In fact, btrfs has already used "recovery" mount option.
>>     Using "norecovery" mount option will be quite confusing for btrfs.
>
> Too bad btrfs picked those semantics when "norecovery" has existed on
> other filesystems for quite some time with a different meaning... :(
>
>> 2) More straight forward mount option
>>     Currently, to get real RO mount, for ext4/xfs, user must use -o
>>     ro,norecovery.
>>     Just ro won't ensure real RO, and norecovery can't be used alone.
>>     If we have a simple alias, it would be much better for user to use.
>>     (it maybe done just in user space mount)
>
> mount(8) simply says:
>
>         ro     Mount the filesystem read-only.
>
> and mount(2) is no more illustrative:
>
>         MS_RDONLY
>                Mount file system read-only.
>
> kernel code is no help, either:
>
> #define MS_RDONLY        1      /* Mount read-only */
>
> They say nothing about what, exactly, "read-only" means.  But since at least
> the early ext3 days, it means that you cannot write through the filesystem, not
> that the filesystem will leave the block device unmodified when it mounts.
>
> I have always interpreted it as simply "no user changes to the filesystem,"
> and that is clearly what the vfs does with the flag...
>
>>     Not to mention some fs (yeah, btrfs again) doesn't have "norecovery"
>>     but "nologreplay".
>
> well, again, btrfs picked unfortunate semantics, given the precedent set
> by other filesystems.
>
> f2fs, ext4, gfs2, nilfs2, and xfs all support "norecovery" - xfs since
> forever, ext4 & f2fs since 2009, etc.

I understand it's btrfs' fault.
Considering how many filesystems are already using "norecovery", it is 
almost a standard.

Not sure if it's possible to change the "recovery" mount option to other 
name for btrfs, but it seems using "norecovery" would be the best solution.

>
>> 3) A lot of user even don't now mount ro can still modify device
>>     Yes, I didn't know this point until I checked the log replay code of
>>     btrfs.
>>     Adding such mount option alias may raise some attention of users.
>
> 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.

Thanks,
Qu
>
> If you want to be sure your block device rejects all IO for forensics or
> what have you, I'd suggest # blockdev --setro /dev/whatever prior to mount,
> and take it out of the filesystem's control.  Or better yet, making an
> image and not touching the original.
>
> -Eric
>
>> Any ideas about this?
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Christoph Anton Mitterer]

[-- Attachment #1.1: Type: text/plain, Size: 4759 bytes --]

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

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Eric Sandeen]

On 12/17/15 8:01 PM, Christoph Anton Mitterer wrote:
> 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".

<lots of words snipped>

Karel pointed out that recent mount(8) says:

>    -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.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Christoph Anton Mitterer]

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

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Stewart Smith]

[-- Attachment #1.1: Type: text/plain, Size: 1456 bytes --]

Eric Sandeen <sandeen@redhat.com> writes:
>> 3) A lot of user even don't now mount ro can still modify device
>>    Yes, I didn't know this point until I checked the log replay code of
>>    btrfs.
>>    Adding such mount option alias may raise some attention of users.
>
> 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.
>
> If you want to be sure your block device rejects all IO for forensics or
> what have you, I'd suggest # blockdev --setro /dev/whatever prior to mount,
> and take it out of the filesystem's control.  Or better yet, making an
> image and not touching the original.

What we do for the petitboot bootloader in POWER and OpenPower firmware
(a linux+initramfs that does kexec to boot) is that we use device mapper
to make a snapshot in memory where we run recovery (for some
filesystems, notably XFS is different due to journal not being endian
safe). We also have to have an option *not* to do that, just in case
there's a bug in journal replay... and we're lucky in the fact that we
probably do have enough memory to complete replay, this solution could
be completely impossible on lower memory machines.

As such, I believe we're the only bit of firmware/bootloader ever that
has correctly parsed a journalling filesystem.

-- 
Stewart Smith

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Dave Chinner]

On Thu, Dec 24, 2015 at 10:22:31AM +1100, Stewart Smith wrote:
> Eric Sandeen <sandeen@redhat.com> writes:
> >> 3) A lot of user even don't now mount ro can still modify device
> >>    Yes, I didn't know this point until I checked the log replay code of
> >>    btrfs.
> >>    Adding such mount option alias may raise some attention of users.
> >
> > 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.
> >
> > If you want to be sure your block device rejects all IO for forensics or
> > what have you, I'd suggest # blockdev --setro /dev/whatever prior to mount,
> > and take it out of the filesystem's control.  Or better yet, making an
> > image and not touching the original.
> 
> What we do for the petitboot bootloader in POWER and OpenPower firmware
> (a linux+initramfs that does kexec to boot) is that we use device mapper
> to make a snapshot in memory where we run recovery (for some
> filesystems, notably XFS is different due to journal not being endian
> safe). We also have to have an option *not* to do that, just in case
> there's a bug in journal replay... and we're lucky in the fact that we
> probably do have enough memory to complete replay, this solution could
> be completely impossible on lower memory machines.

Which means the boot loader is going to break horribly when we
change the on-disk format and feature flags the boot loader doesn't
understand get set in the root filesystem. Then the bootloader will
refuse to mount the filesystem and the system won't boot anymore...

IOWs, developers and users can't make a root XFS filesystem with a
new/experimental feature on POWER/OpenPower machines because the
bootloader will refuse to mount it regardless of the clean/dirty
state of the journal....

> As such, I believe we're the only bit of firmware/bootloader ever that
> has correctly parsed a journalling filesystem.

Nope.  The Irix bootloader (sash) could do this 20 years ago - there
are even feature mask bits reserved specifically for SASH in the XFS
superblock. However, seeing as the bootloader was always upgraded
during the install of each new Irix release, the bootloader was
always up-to-date with the on-disk features the kernel supported and
so there was never a problem with mismatched feature support.

However, Linux users can upgrade or change the kernel at any time
independently of the bootloader, so it's pretty much guaranteed that
mismatched bootloader/kernel filesystem capabilities will cause
users problems at some point in the not-too-distant future.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs