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

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

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

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 #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]