On 2012-04-28, at 8:19, Ted Ts'o <tytso@xxxxxxx> wrote: > On Tue, Mar 06, 2012 at 12:49:41PM -0800, Darrick J. Wong wrote: >> @@ -177,11 +189,17 @@ typedef struct journal_block_tag_s >> __be32 t_blocknr; /* The on-disk block number */ >> __be32 t_flags; /* See below */ >> __be32 t_blocknr_high; /* most-significant high 32bits. */ >> + __be32 t_checksum; /* crc32c(uuid+seq+block) */ >> } journal_block_tag_t; >> >> #define JBD2_TAG_SIZE32 (offsetof(journal_block_tag_t, t_blocknr_high)) >> #define JBD2_TAG_SIZE64 (sizeof(journal_block_tag_t)) > > There's a problem with this patch here --- we are changing the size of > journal_block_tag_t, which is an on-disk data structure. So for > 64-bit journals, this represents a format change. This means that if > you have a 64-bit file system that needs to have its journal > recovered, if the journal was written with an older kernel, and then > we try to recover it with a new kernel, things won't be good. > Similarly, for e2fsck's recovery code, it's not going to be able to > recover 64-bit file systems using current coding, since this patch > series changes the size of JBD2_TAG_SIZE64. > > What we need to do is something like this: > > #define JBD2_TAG_SIZE64 (offsetof(journal_block_tag_t, t_checksum)) > #define JBD2_TAG_SIZE_CSUM (sizeof(journal_block_tag_t)) > > And then change the code appropriately in e2fsprogs and in the kernel > to use the correct tag size depending on the journal options. I thought we originally discussed using the high 16 bits of the t_flags field to store the checksum? This would avoid the need to change the disk format. Since there is still a whole transaction checksum, it isn't so critical that the per-block checksum be strong. One idea is to do the crc32c for each block, then store the high 16 bits into t_flags, and checksum the full 32-bit per-block checksums to make the commit block checksum, to avoid having to do the block checksums twice. Cheers, Andreas-- 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
