Hi Ted,
On Sat, 2008-05-24 at 18:34 -0400, Theodore Ts'o wrote:
> I've been taking a much closer look at the ext4's journal checksum code
> as I integrated it into e2fsck, and I'm finding that what it's doing
> doesn't make a whole lot of sense.
>
> Suppose the journal has five commits, with transaction ID's 2, 3, 4, 5,
> and 6. And suppose the CRC in the commit block delineating the end of
> transaction #4 is bad. At the moment, due to a bug in the code, it
> stops processing at transaction #4, meaning that transactions #2, #3,
> and #4 are replayed into the filesystem --- even though transaction #4
> failed the CRC checksum.
I went through the code and also re-ran the e2fsprogs tests which we had
sent upstream for journal checksum. And found that if the transaction is
bad it is marked as info->end_transaction which indicates a bad
transaction and is not replayed.
if (chksum_err) {
info->end_transaction = next_commit_ID;
The end_transaction is set to transaction ID which is found to be
corrupt. So #4 will be set in end_transaction and in PASS_REPLAY the
last transaction to be replayed will be #3 due to this:
----------------------------------------------------------------
if (tid_geq(next_commit_ID, info->end_transaction))
break;
-----------------------------------------------------------------
if (!JFS_HAS_COMPAT_FEATURE(journal,
JFS_FEATURE_INCOMPAT_ASYNC_COMMIT)){
printk(KERN_ERR "JBD: Transaction %u found to be corrupt.\n",
next_commit_ID);
brelse(bh);
break;
}
}
> Worse yet, no indication of any problems is
> sent back to the ext4 filesystem code.
This definitely is not present and needs to be incorporated.
Thanks,
Girish
--
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
