On 2015-11-30 10:28, Hugo Mills wrote:
On Mon, Nov 30, 2015 at 09:59:40AM -0500, Austin S Hemmelgarn wrote:
On 2015-11-28 08:46, 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).
This is exactly how it should behave (being able to say that a RO
mount is really RO (if atimes aren't enabled) is a huge selling
point).  On a side note, a properly designed journaling filesystem
_can_ be made to behave like this, but it makes the filesystem
_really_ slow if you don't have enough RAM to cache all the blocks
modified by the journal (because each block access has to check the
journal for modifications).

    So, this looks to me like a regression that's come in somewhere.
I'm not sure that this ever worked the way it should.  It should be
fixed regardless of what state things were however.

    I'm pretty sure it was like that at some point, because I've used
it as a diagnostic tool: If you can mount OK with -oro, but not
without, then the log tree is broken, and btrfs-zero-log can be used
to good effect. (In fact, that's what I was trying to do with the OP
when I spotted the issue).
Hmm, in that case, it looks like a bisection is in order, but that may be tough without a known broken filesystem image. I would offer to try and bisect it myself, but I seem to have misplaced the scripts I had been using to automate testing, and I won't be able to take the time to look for them properly (and possibly re-write them) until this weekend.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to