On Thu, Apr 04, 2024 at 09:36:54PM +0800, Wang Jianjian wrote: > journal_tag_t has already counted the checksum size, however, for > compatibility reason, we don't fix this bug and keep it as is. > > Signed-off-by: Wang Jianjian <wangjianjian0@xxxxxxxxxxx> The csum_v2 layout had a number of problems, which was documented in commit db9ee220361de: jbd2: fix descriptor block size handling errors with journal_csum It turns out that there are some serious problems with the on-disk format of journal checksum v2. The foremost is that the function to calculate descriptor tag size returns sizes that are too big. This causes alignment issues on some architectures and is compounded by the fact that some parts of jbd2 use the structure size (incorrectly) to determine the presence of a 64bit journal instead of checking the feature flags. Therefore, introduce journal checksum v3, which enlarges the descriptor block tag format to allow for full 32-bit checksums of journal blocks, fix the journal tag function to return the correct sizes, and fix the jbd2 recovery code to use feature flags to determine 64bitness. Add a few function helpers so we don't have to open-code quite so many pieces. Switching to a 16-byte block size was found to increase journal size overhead by a maximum of 0.1%, to convert a 32-bit journal with no checksumming to a 32-bit journal with checksum v3 enabled. We switched to using csum_v3 in 2014, in Linux v3.17. So most recent LTS kernel which used the v2 csum format was Linux v3.14 which EOL'ed in 2016 --- a full eight years ago. So it's probably not worth adding the comment at this point. In fact, what we might want to consider is yanking support for the CSUM_v2 and CSUM_V1 at this point, since *all* currently supported LTS kernels (4.19, 5.4, 5.10, 5.15, 6.1 and 6.6) will be using CSUM_V3. It's not actually *that* much code, but what's there is a bit hard to understand since it very much relies on how the v2 and v3 data strutures line up with each other, and the fact that the jbd2 structures are stored on disk in big_endian. - Ted