On Sep 8, 2014, at 5:11 PM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > Patch 1 introduces journal_csum v3 to fix numerous journal block tag > size handling bugs when metadata_csum+journal_checksum are turned on. > The test of 64bitness should not rely on guessing the tag size when it > could simply query the feature flags, since it was guessing > incorrectly. Furthermore, the journal_csum v2 structure had memory > access alignment issues. Just replace this all with a 16-byte tag > with everything in it; the overhead for checksums is no more than > 0.1%. It's really too bad that we are introducing a new journal checksum feature, when the current journal checksum implementation is essentially unusable. Any minor corruption in one transaction block that has following un-checkpointed transactions will almost certainly result in _more_ corruption of the filesystem rather than less, due to all of the *committed* but uncheckpointed blocks being discarded from the journal. This would also result in a silent rollback of filesystem state and loss of user data if running with data=journal. As a result, there is no practical value (IMHO) to enabling this feature at all currently. We've discussed in the past that having per-block checksums is necessary in order to fix this, so that only corrupt blocks in the journal are skipped during replay, and may not result in any visible filesystem corruption if the blocks are overwritten later during replay. Otherwise, this will itself result in yet a new block tag format and journal checksum feature. Is there any chance you could take a look at implementing this as part of journal_checksum_v3 instead of fixing the current bugs only to have a "correctly working" but not usable feature? Cheers, Andreas > NOTE: The test "j_corrupt_journal_block" in patch 21 ensures that > e2fsck will replay everything but the corrupt block, and then proceeds > with the fsck to fix up whatever might be broken. You can decompress > the image.gz and try to mount it to verify that it's unmountable (and > hence requires e2fsck to be run). > > Patches 23-25 implement v2 of the e2fsck readahead functionality, > which promises to reduce fsck runtime by 10-30%. You might want to > read the report: http://marc.info/?l=linux-ext4&m=140755433701165&w=2 > ("e2fsck readahead speedup performance report") for all the juicy > details! > > I've tested these e2fsprogs changes against the -next branch as of > 8/29. The patches have been tested against the 'make check' suite and > some amount of e2fuzz testing. > > Comments and questions are, as always, welcome. > > --D > -- > 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 Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
