New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Forced writes do not work on Linux [CORE1476] #1892
Comments
Commented by: @dyemanov Is it possible to backport the fix into 2.0.4? |
Commented by: @AlexPeshkoff It's much desired, but we have one problem. |
Modified by: @dyemanovdescription: To make disk writes return ony after data is actually placed on disk (not only to OS cache), fcntl() system call is used. It was supposed to set flag O_SYNC, making cache write-transparent. But, according to linux documentation: For firebird this all leads to ability to have database broken even with FW=ON. Which is actually known to happen on linux. => To make disk writes return only after data is actually placed on disk (not only to OS cache), fcntl() system call is used. It was supposed to set flag O_SYNC, making cache write-transparent. But, according to Linux documentation: For Firebird this all leads to ability to have database broken even with FW=ON. Which is actually known to happen on Linux. environment: linux => Linux, possibly other POSIX platforms too summary: On linux forced writes do not work. => Forced writes do not work on Linux |
Commented by: @ibaseru Excuse me, but description of this issue does not specify is this related only to kernel 2.6, or to 2.4 and other kernel versions also. |
Commented by: @AlexPeshkoff I have reviewed kernel sources only as a last chance. I've hoped that what I see in documentation and what I get with firebird is a kind of mistake, my mistake and doc's writer mistake. See yourself - system call, NOT doing what one asks it to do (i.e. set flag O_SYNC), returns success instead of error! And this awful behavior is documented! Yes, I know that 'documented bug becomes feature', but... I'm pretty sure taht all older linux versions do have same behavior - or what we have now is serious regression in 2.6, which could not stay unnoticed for years. Moreover, man is independent from kernel, installing newer kernel does not change man pages regarding system calls. And what we have is documented in it. |
Commented by: @AlexPeshkoff There is interesting article in linux kernel tracker: The test provided in that article shows that a lot of unixes (including FreeBSD, Solaris and HPUX) are OK from this POV. Certainly, it will be useful to test that operating systems better. |
Modified by: @AlexPeshkoffFix Version: 2.1 Beta 2 [ 10190 ] |
Modified by: @pcisarWorkflow: jira [ 13152 ] => Firebird [ 15334 ] |
Commented by: @AlexPeshkoff Backported without serious performance optimization. |
Modified by: @AlexPeshkoffstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 2.0.4 [ 10211 ] |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @pavel-zotovQA Status: No test |
Modified by: @pavel-zotovstatus: Closed [ 6 ] => Closed [ 6 ] QA Status: No test => Cannot be tested |
Submitted by: @AlexPeshkoff
Votes: 1
To make disk writes return only after data is actually placed on disk (not only to OS cache), fcntl() system call is used. It was supposed to set flag O_SYNC, making cache write-transparent. But, according to Linux documentation:
"On Linux this command (i.e. fcntl(fd, F_SETFL, flags)) can only change the O_APPEND, O_ASYNC, O_DIRECT, O_NOATIME, and O_NONBLOCK flags."
Review of kernel source code (2.6.19) and direct speed tests with various open() / fcntl() flags showed that flag O_SYNC is really not affected on Linux. Attempt to set it does not make error to be returned by fcntl(). Moreover, attempt to check current flag's state shows that O_SYNC is set, but actually write() does not send data to disk to the moment of system call return.
For Firebird this all leads to ability to have database broken even with FW=ON. Which is actually known to happen on Linux.
Commits: f712b3a c06199f df35551 fd52a57
The text was updated successfully, but these errors were encountered: