On Thu, Dec 8, 2022 at 7:28 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.
MariaDB does the same as the filesystem
InnoDB in fact is more ore less a FS on top of a FS
So why do it at both levels? And what makes doing it at MariaDB level
in any way better than doing it somewhere else?
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.
"Some of us run MariaDB on file systems that do their own block
checksumming, and thus run innodb_checksum_algorithm=none" makes you
looking like a fool - period
are you dumb or why don't you understand that the filesystem is a
completly different layer and has no clue about the data itself?
Are you too dumb to understand that if a block is corrupted at InnoDB
level MariaDB can't do anyting to fix it, but if a block is corrupted
at lower level, ZFS can fix it from redundantly stored data and
MariaDB never gets to ingest a corrupted block in the first place?
If you disagree, please describe a scenario in which an InnoDB page
checksum does anything useful if the file system it is on has built in
block checksumming and data redundancy.
_______________________________________________
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~maria-discuss
More help : https://help.launchpad.net/ListHelp
