Re: xt4 - True Readonly mount [WAS - Re: [Bug 14354] Bad corruption with 2.6.32-rc1 and upwards]

[Theodore Tso <tytso@mit.edu>]

On Fri, Oct 30, 2009 at 10:20:35AM -0400, Greg Freemyer wrote:
> Ignoring computer forensics, with LVM snapshots, hardware raid array
> snapshots, etc. even in the presence of a dirty log, we need to be
> able to mount a drive in true read-only fashion fro many backup
> operations to function correctly.

Can you go into more detail about "many backup operations"?   

> XFS added an extra mount flag for that 5 or so years ago.

As Eric has already pointed out, "norecovery" and "noload" mean the
same thing.  But not recovering the journal is dangerous; the file
system is not necessarily going to be consistent, and while the kernel
_shouldn't_ crash given an inconsistent filesystem image --- and a lot
of fsfuzzer testing and bug fixing means that it _probably_ won't
crash --- taking a backup of an inconsistent file system image due to
the journal recovery being suppressed isn't such a great idea.

As I mentioned, trying to _simulate_ a journal recovery by using the
journal instead of data blocks for those blocks in the journal is
possible, but it's a non-trival task to code up.  A Google Summer of
Student project could probably do it, but it's not a day or half-day
project.

If someone is interested in simulating a journal recovery in a true ro
fashion, I'm happy to lay out the design for such a thing.  Contact me
if you're interested....

						- Ted

P.S.  We can certainly add an alias so that ext4 understands
norecovery much like XFS does.  If we are going to standardize on a
mount option, I'd agree that XFS's norecovery is probably a better
choice than ext3/4's noload.