[MDEV-30069] InnoDB: Trying to write ... bytes at ... outside the bounds of the file ... Created: 2022-11-22 Updated: 2023-02-02 Resolved: 2022-11-22 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB |
| Affects Version/s: | 10.6, 10.7, 10.8, 10.9, 10.10, 10.11 |
| Fix Version/s: | 10.11.2, 10.6.12, 10.7.8, 10.8.7, 10.9.5, 10.10.3 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Marko Mäkelä | Assignee: | Marko Mäkelä |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | regression-10.6, rr-profile-analyzed | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||
| Description |
|
For the dataset in
Before the failure, there was one call to fil_system_t::extend_to_recv_size() from recv_sys.apply_log(false).
As far as I can tell, the problem should be fixed by extending the tablespace before invoking buf_LRU_get_free_block(), at least in recv_sys_t::recover_low() and possibly elsewhere (definitely when I was not able to reproduce the error for a copy of the data directory, so some additional testing will be needed. |
| Comments |
| Comment by Matthias Leich [ 2022-11-22 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Marko Mäkelä [ 2022-11-22 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The fix that I initially had in mind is too complex, could cause a performance regression, and actually cannot fix the failure. In the rr replay trace, fil_ibd_load() is being invoked multiple times on the file test/t5.ibd, and each time it returns FIL_LOAD_DEFER, which the caller does not make note of (MDEV-25909). Each of those calls also invokes os_file_get_size() but throws away the result. The data set that I uploaded to I should have copied the data directory before the restart attempt. In that data directory, the file test/t5.ibd consists of 448*65536 NUL bytes. This problem was caused by As far as I can tell, a second attempt to recover the data directory should succeed. The FSP_SIZE in page 0 of the file will be recovered to 0x1c0 (448) pages on my system, while in the data directory that I attached to Finally, I was able to reproduce this with data.tar.xz
Like in the rr replay trace, the tablespace size is 10 and the recv_size is 448 pages at this point. I think that the problem occurs when a created data file is recovered during an earlier batch of recovery. At that point, we fail to read the file size metadata from the file system. |