Checksum Algorithms

IDB Utils supports three checksum algorithms used by different InnoDB implementations and versions.

CRC-32C (MySQL 5.7.7+ default)

The default algorithm since MySQL 5.7.7. It computes the XOR of two independent CRC-32C values over non-overlapping byte ranges:

  • Range 1: bytes [4..26) -- covers page number, prev/next pointers, LSN, and page type
  • Range 2: bytes [38..page_size-8) -- covers the entire page body
[checksum][--- Range 1 ---][flush_lsn+space_id][------- Range 2 -------][trailer]
 0    3  4             25  26              37  38                    PS-8   PS

The two CRC-32C values are computed independently (not chained) and XORed together. The result is stored in bytes 0-3 of the page (the FIL header checksum field).

CRC-32C is hardware-accelerated on modern x86 (SSE 4.2) and ARM (CRC extension) processors, making validation fast even for large tablespaces.

Legacy InnoDB (MySQL < 5.7.7)

The original InnoDB checksum algorithm, used as the default before MySQL 5.7.7. It uses the internal ut_fold_ulint_pair function with wrapping u32 arithmetic.

The algorithm processes bytes one at a time (not as u32 words) over the same two byte ranges as CRC-32C:

  • Range 1: bytes [4..26)
  • Range 2: bytes [38..page_size-8)

The fold function accumulates a running hash by combining each byte with the previous hash value using wrapping multiplication, addition, and XOR operations. The final result is the sum of the fold values from both ranges.

The legacy checksum is stored in the same location as CRC-32C: bytes 0-3 of the page.

Mixed Mode

MySQL 5.7.x supports innodb_checksum_algorithm values of crc32, innodb, none, and strict_* variants. During migration from legacy to CRC-32C, a tablespace may contain pages with either algorithm. inno checksum validates against both algorithms and reports a page as valid if either checksum matches.

MariaDB full_crc32 (MariaDB 10.5+)

MariaDB 10.5 introduced a simplified checksum format called full_crc32:

  • Single CRC-32C computed over bytes [0..page_size-4) -- covers nearly the entire page
  • Checksum location: stored in the last 4 bytes of the page, not in the FIL header
[------------- CRC-32C input ---------------][checksum]
 0                                        PS-4    PS

This differs from the MySQL format in two important ways:

  1. The checksum covers bytes 0-3 (which are skipped in the MySQL CRC-32C algorithm), providing stronger integrity protection
  2. The checksum is stored at the end of the page rather than the beginning

Detection

MariaDB full_crc32 is detected via FSP flags bit 4 on page 0. When this bit is set, inno automatically uses the full_crc32 algorithm for all pages in the tablespace.

Validation Behavior

inno checksum validates each page using the appropriate algorithm:

  1. Check FSP flags on page 0 for MariaDB full_crc32 -- if detected, use that for all pages
  2. Otherwise, compute both CRC-32C and Legacy checksums
  3. A page is valid if its stored checksum matches either computed value
  4. Pages with all-zero content (empty/allocated pages) are reported separately and not counted as invalid
  5. LSN consistency is checked independently: the low 32 bits of the header LSN must match the trailer value

Use inno checksum -v for per-page details or inno checksum --json for structured output.