Folks, Upon raising https://jira.mariadb.org/browse/MDEV-27900, and reraising it to the btrfs kernel developers, Filipe Manana (Suse) came up with this patch. https://lore.kernel.org/linux-btrfs/CABVffENfbsC6HjGbskRZGR2NvxbnQi17gAuW65e... As a regression to 51bd9563b6783d, this affects all 5.16 kernels. Bug report will contain an error log like: 2022-02-21 14:59:31 0 [ERROR] InnoDB: Database page corruption on disk or a failed read of file './ibdata1' page [page id: space=0, page number=9]. You may have to recover from a backup. 2022-02-21 14:59:31 0 [Note] InnoDB: Page dump in ascii and hex (16384 bytes): len 16384; hex 0000000000000009ffffffffffffffff0000000000009c2045bf0000000000000000000000000002012022-02-21 14:59:31 0 [ERROR] InnoDB: Database page corruption on disk or a failed read of file './ibdata1' page [page id: space=0, page number=243]. You may have to recover from a backup. 710009002022-02-21 14:59:31 0 [Note] InnoDB: Page dump in ascii and hex (16384 bytes): This has occurred exclusively on btrfs so far, however there are suggestions on the linux-fsdevel list that gfs2 can also experience the same. It's important to note, the users' data isn't corrupt, just MariaDB's read of it. Until a kernel update is prepared they can work around the bug with innodb_use_native_aio=0 or innodb_flush_method=fsync as MariaDB configuration items. Changing these settings the user's data is visible again. In the meantime, I'm working on MDEV-27593 InnoDB handle AIO errors with message rather than assertion, to better validate and handle error code, and returned sizes apparently. Thanks, Daniel Black Chief Innovation Officer MariaDB Foundation