On 2015-11-28 08:46, Hugo Mills wrote:
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).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).
I'm not sure that this ever worked the way it should. It should be fixed regardless of what state things were however.So, this looks to me like a regression that's come in somewhere.
smime.p7s
Description: S/MIME Cryptographic Signature