All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hugo Mills <hugo@carfax.org.uk>
To: Chris Mason <clm@fb.com>,
	Btrfs mailing list <linux-btrfs@vger.kernel.org>
Subject: Re: Bug/regression: Read-only mount not read-only
Date: Mon, 30 Nov 2015 17:06:00 +0000	[thread overview]
Message-ID: <20151130170600.GC8775@carfax.org.uk> (raw)
In-Reply-To: <20151130164801.GD2162@ret.masoncoding.com>

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

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.

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

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

   Hugo.

-- 
Hugo Mills             | argc, argv, argh!
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2015-11-30 17:06 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-28 13:46 Bug/regression: Read-only mount not read-only Hugo Mills
2015-11-30 14:59 ` Austin S Hemmelgarn
2015-11-30 15:28   ` Hugo Mills
2015-11-30 16:00     ` Austin S Hemmelgarn
2015-11-30 16:48 ` Chris Mason
2015-11-30 17:06   ` Hugo Mills [this message]
2015-12-01 19:00     ` Chris Mason
2015-12-01 19:05       ` Eric Sandeen
2015-12-02  6:25         ` Russell Coker
2015-12-02  9:06           ` Qu Wenruo
2015-12-02  9:23             ` Qu Wenruo
2015-12-02 16:54               ` Eric Sandeen
2015-12-02 17:48                 ` Austin S Hemmelgarn
2015-12-02 18:53                   ` Hugo Mills
2015-12-02 22:48                   ` Eric Sandeen
2015-12-02 23:40                     ` Qu Wenruo
2015-12-02 23:51                       ` Hugo Mills
2015-12-03  6:44                         ` Duncan
2015-12-04 12:32                         ` Austin S Hemmelgarn
2015-12-04 12:23                       ` Austin S Hemmelgarn
2015-11-30 17:08   ` Austin S Hemmelgarn
2015-12-01  6:46   ` Qu Wenruo
2015-12-01 18:54     ` Chris Mason
2015-12-01 23:47       ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151130170600.GC8775@carfax.org.uk \
    --to=hugo@carfax.org.uk \
    --cc=clm@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.