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
