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

[Stewart Smith <stewart@flamingspork.com>]

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