On Thu, Dec 8, 2022 at 7:02 PM Reindl Harald <[email protected]> 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. _______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
