maria-discuss team mailing list archive

[Gordan Bobic <gordan.bobic@xxxxxxxxx>]

On Thu, Dec 8, 2022 at 7:02 PM Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:

> >> MariaDB Server 10.4 introduced a new file format
> >> innodb_checksum_algorithm=full_crc32, and MariaDB Server 10.5 made it
> >> the default. Any files that were created when that setting is active
> >> are guaranteed to write any unused bytes as zeroes. It also fixes a
> >> peculiar design decision that some bytes of the page are not covered
> >> by any checksum, and that a page is considered valid if any of the
> >> non-full_crc32 checksums happen to produce a match. This includes the
> >> magic 0xdeadbeef for innodb_checksum_algorithm=none.
> >>
> >> Maybe we should consider eventually deprecating write support for the
> >> non-full_crc32 format, to force a fresh start.
> >
> > Please don't. Some of us run MariaDB on file systems that do their own
> > block checksumming, and thus run innodb_checksum_algorithm=none
>
> that's nonsense - when mariadb writes wrong data in it's files no
> filesystem can magically fix that

MariaDB can't fix it either. And if that is what happened, there is no
benefit to duplicating the effort.

> you need to understand what innodb checksums are and then it's logical
> that the file-system layer is a completly different world
>
> https://dba.stackexchange.com/questions/171708/what-is-an-innodb-page-checksum

You need to understand that properly thought out and sensibly written
file systems (which is, granted, pretty rare, I know of a total of 1)
implicitly prevent torn pages from being possible.
So the checksum and the doublewrite are completely redundant in such
cases, and can be safely disabled.