Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.5.2
Description
The function os_file_punch_hole() would return DB_IO_NO_PUNCH_HOLE if the underlying file system does not support the operation. This error code is silently transformed to DB_SUCCESS in IORequest::punch_hole().
In MDEV-15528, a call to os_file_punch_hole() was added to fil_io() but the return value DB_IO_NO_PUNCH_HOLE is not being tolerated.
If the data directory resides in a file system that does not support the hole-punching, then the following test would crash:
./mtr innodb.innodb-page_compression_zip
|
10.5 4ec032b492de5c392f66c9c1764cbf72442ed3a9 |
CURRENT_TEST: innodb.innodb-page_compression_zip
|
mysqltest: At line 93: query 'update innodb_page_compressed1 set c1 = c1 + 1' failed: 2013: Lost connection to MySQL server during query
|
…
|
2020-07-22 10:51:37 0x7f71b9694700 InnoDB: Assertion failure in file /mariadb/10.5m/storage/innobase/fil/fil0fil.cc line 3919
|
InnoDB: Failing assertion: req_type.is_dblwr_recover() || err == DB_SUCCESS
|
An example of such a file system is encfs 1.9.5 set up on top of ext4 on Debian GNU/Linux.
Note: A file system that does not support hole-punching will make the use of page_compressed tables pointless. Maybe we should issue some error on CREATE TABLE already? But that is a separate bug.
Attachments
Issue Links
- is blocked by
-
MDEV-23254 Replace FSP_FLAGS_HAS_PAGE_COMPRESSION with fil_space_t::is_compressed
- Closed
- is caused by
-
MDEV-15528 Avoid writing freed InnoDB pages
- Closed