Re: Bug/regression: Read-only mount not read-only

[Chris Mason <clm@fb.com>]

On Mon, Nov 30, 2015 at 05:06:00PM +0000, Hugo Mills wrote:
> On Mon, Nov 30, 2015 at 11:48:01AM -0500, Chris Mason wrote:
> > On Sat, Nov 28, 2015 at 01:46:34PM +0000, Hugo Mills wrote:
> > >    We've just had someone on IRC with a problem mounting their FS. The
> > > main problem is that they've got a corrupt log tree. That isn't the
> > > subject of this email, though.
> > > 
> > >    The issue I'd like to raise is that even with -oro as a point
> > > option, the FS is trying to replay the log tree. The dmesg output from
> > > mount -oro is at the end of the email.
> > > 
> > >    Now, my memory, experience and understanding is that the FS
> > > doesn't, and shouldn't replay the log tree on a RO mount, because the
> > > FS should still be consistent even without the reply, and
> > > RO-means-actually-RO is possible and desirable. (Compared to a
> > > journalling FS, where journal replay is required for a consistent,
> > > usable FS).
> > > 
> > >    So, this looks to me like a regression that's come in somewhere.
> > > 
> > >    (Just for completeness, the system in question usually runs 4.2.5,
> > > but the live CD the OP is using is 4.2.3).
> > 
> > We do need to replay the log tree, even on readonly mounts.  Otherwise
> > files created and fsunk before crashing may not even exist.
> 
>    I'm actually happy with that, as long as the log tree is retained
> until it _can_ be played back. I think it's much more important that
> read-only actually means read-only *as much as is possible* (if for no
> other reason than being able to test the status of the log tree).
> Obviously, for journalling FSes, a journal reply is required by the
> design of the FS, but with a CoW FS, the FS should be consistent if
> possibly outdated with a RO mount.

Normally I'd agree, but we have a long tradition of mounting root
readonly at first for no good reason at all.  This is why reiserfs/ext
(and I think xfs) all replay logs on readonly mounts.  It's not an
admin initiated action but an early stage of boot.

> 
>    Maybe there should be a "replay-log" mount option to modify the
> "ro" option to allow the log to be replayed but no further
> modifications? (i.e. keep the plain "ro" case to be the safest option
> that makes the fewest changes to the FS structure -- none).
> 

I'd do it the other way around, have a mount option that is emergency
readonly.

> > We'll bail out of the log replay on readonly media, but otherwise the
> > replay always happens.
> 
>    OK, so what was happening in the cases where a filesystem was
> mountable RO, but not RW, and then btrfs-zero-log allowed the FS to be
> mounted? I've handled any number of people with exactly those
> symptoms, and it's been like that for a while. What I saw on IRC a
> couple of days ago seems to be new behaviour.

Something else was being skipped, probably btrfs_cleanup_fs_roots()

-chris