Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
5.5.24
-
None
-
None
Description
I discovered a serious problem in 5.5 related to fsync (5.3 and below appears
not affected).
By default, we do not run any fsync at all. This is because the
--debug-no-sync option is incorrectly enabled by default.
This problem was introduced here:
revid:sergii@pisem.net-20111212225840-8aotf02a1alw1gta
- {"sync_sys", 0,
- "Enable system sync calls. Disable only when running tests or debugging!",
- &opt_sync, &opt_sync, 0, GET_BOOL, NO_ARG, 1, 0, 0, 0, 0, 0}
,
{"debug-no-sync", 0, + "Disables system sync calls. Only for running tests or debugging!", + &my_disable_sync, &my_disable_sync, 0, GET_BOOL, NO_ARG, 1, 0, 0, 0, 0, 0}
+,
The option was renamed and the meaning was reversed - but the default was left
unchanged, effectively reversing the default.
We need to fix this ASAP, as it causes data loss / silent corruption when the
host machine crashes.
There is an additional problem that even with --debug-no-sync=0, we are using
fsync(), not fdatasync() as we should. There is code to use fdatasync(), but
apparently availability of fdatasync() is not correctly detected by
cmake. This is also a quite serious issue; one one machine I tested with a
good RAID controller, fdatasync() is 2.5 times faster than fsync().
Work-around: pass --debug-no-sync=0 in config or on command line (but this will not fix fdatasync() performance problem).