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). Hugo. -- Hugo Mills | You are not stuck in traffic: you are traffic hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 | German ad campaign
signature.asc
Description: Digital signature
