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

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

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

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.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]