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. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
