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@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
