Op 08-12-2022 om 18:59 schreef Gordan Bobic:
On Thu, Dec 8, 2022 at 7:28 PM Reindl Harald <h.reindl@thelounge.net> 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-checks... 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
I don't understand much of this discussion, but take it it's not meant for me... I take it it does not change anything for the steps I described in my last mail. to get a functioning database again.. regards, Jogchum