[MDEV-33295] innodb.doublewrite,64k,strict_crc32 occasionally fails Created: 2024-01-22 Updated: 2024-01-22 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB, Tests |
| Affects Version/s: | 10.11 |
| Fix Version/s: | 10.11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Marko Mäkelä | Assignee: | Marko Mäkelä |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | corruption | ||
| Environment: |
Linux version 6.6.11-amd64 (debian-kernel@lists.debian.org) (gcc-13 (Debian 13.2.0-9) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41.50.20231227) #1 SMP PREEMPT_DYNAMIC Debian 6.6.11-1 (2024-01-14) |
||
| Issue Links: |
|
||||||||
| Description |
|
I am not yet sure what is to blame here. The following test invocation would occasionally fail:
This would fail due to corruption of the tables mysql.innodb_index_stats or mysql.innodb_table_stats, like this:
The first page of the data file would look as follows:
The error is that the first 4 bytes are 0x1000000 big-endian instead of a copy of the checksum bytes that are at 0xfff8 near the end of the page. It is notable that during the test, this table should not be modified. The FIL_PAGE_LSN (in the above case 0xb3d3) is smaller than the LSN after the end of the bootstrap. I was able to reproduce the failure also by running exclusively the strict_crc32 combination, and always for the 64k page size. But I can’t seem to be able to reproduce it when invoking the following:
The test is running on /dev/shm, and we could get close to exceeding the available RAM. There are a couple of kernel OOM kill messages in the sudo dmesg output, but nothing recently. |
| Comments |
| Comment by Marko Mäkelä [ 2024-01-22 ] | ||||||||||||||
|
The following just completed successfully on the same 10.11 revision:
| ||||||||||||||
| Comment by Marko Mäkelä [ 2024-01-22 ] | ||||||||||||||
|
For the record, the following did not fail either:
One hypothetical explanation of the failure would be some race condition around the serve bootstrap in mtr, when the test is being prepared for different innodb_page_size values. | ||||||||||||||
| Comment by Marko Mäkelä [ 2024-01-22 ] | ||||||||||||||
|
I was not able to reproduce any failure with the 3 smaller page sizes (excluding 32k and 64k):
|