Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.5, 10.6, 10.11, 11.4
-
None
Description
In MDEV-16526 I had written the following:
Craig Ringer on the PostgreSQL mailing list shared a link to his fsync() test program, which suggests fault injection by dmsetup.
I think that we should also investigate the use of virtual machines, that is, possibly flipping the virtual block device read-only at some point of the workload, then killing and restarting the virtual machine. The results should be dependent on the file system used. It could turn out that on some file systems, an fdatasync() on ib_logfile0 will make also the directory contents durable as long as the log and data are located in the same file system.
In MySQL 8.0.38 there was the following change:
Bug#36174938 innodb doesn't call fsync on directories after unlink, rename, open(o_create) (fixup, 2)
The main commit message claims that fsync() needs to be called on directories without naming any file system where this is actually beneficial.
Attachments
Issue Links
- relates to
-
MDEV-381 Data inconsistency (missing rows, extra rows, different rows) between a recovered server and a restored binary log after an imitated HW crash
- Closed