Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.0.11, 10.1.0, 10.2.0, 5.5.55, 10.3.0, 10.4.0
Description
When InnoDB is invoking posix_fallocate() to extend data files, it is missing a call to fsync() to update the file system metadata. If file system recovery is needed, the file size could be incorrect.
Furthermore, when the setting innodb_flush_method=O_DIRECT_NO_FSYNC that was introduced in MariaDB 10.0.11 (and MySQL 5.6) is enabled, InnoDB would stop calling fsync() after extending files.
This report is motivated by a MySQL 5.7.25 change Bug#27309336 Backport to 5.7 that restores the fsync() call. We will fix the bug differently; it does not seem to be a good idea to hold the already contentious fil_system->mutex while executing a system call.
Attachments
Issue Links
- blocks
-
-
- Closed
-
- relates to
-
MDEV-4338 Support FusionIO/directFS atomic writes.
-
- Closed
-
-
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Link |
This issue relates to |
> We will fix the bug differently; it does not seem to be a good idea to hold the already contentious fil_system->mutex while executing a system call.
But os_file_flush() inside fil_flush() already called outside of a mutex.
| issue.field.resolutiondate | 2019-01-23 10:30:31.0 | 2019-01-23 10:30:31.793 |
| Fix Version/s | 10.4.3 [ 23230 ] | |
| Fix Version/s | 10.1.38 [ 23209 ] | |
| Fix Version/s | 5.5.63 [ 23210 ] | |
| Fix Version/s | 10.0.38 [ 23211 ] | |
| Fix Version/s | 10.3.13 [ 23215 ] | |
| Fix Version/s | 10.2.22 [ 23250 ] | |
| Fix Version/s | 10.2 [ 14601 ] | |
| Fix Version/s | 5.5 [ 15800 ] | |
| Fix Version/s | 10.0 [ 16000 ] | |
| Fix Version/s | 10.1 [ 16100 ] | |
| Fix Version/s | 10.3 [ 22126 ] | |
| Fix Version/s | 10.4 [ 22408 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Closed [ 6 ] |
kevg, you are right, the system call in fil_flush() is not covered by a mutex. My mistake.
My solution is not optimal, because in a worst case, it can invoke fsync() twice in a succession: first from os_file_flush() after posix_fallocate() and then possibly from fil_flush(), because in the first call we are not updating the bookkeeping. As always, improvements are welcome.
| Link |
This issue blocks |
| Fix Version/s | 10.4.2 [ 23229 ] | |
| Fix Version/s | 10.4.3 [ 23230 ] |
| Workflow | MariaDB v3 [ 92000 ] | MariaDB v4 [ 155574 ] |
Related to this, there appears to have been a bad merge to MariaDB 10.0.31 and 10.1.24 that caused XtraDB to ignore errors from posix_fallocate().