Skip to content
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

Closed
firebird-automations opened this issue Sep 24, 2007 · 13 comments
Closed

Forced writes do not work on Linux [CORE1476] #1892

firebird-automations opened this issue Sep 24, 2007 · 13 comments

Comments

@firebird-automations
Copy link
Collaborator

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

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Is it possible to backport the fix into 2.0.4?

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

It's much desired, but we have one problem.
Currently it makes sequential insert of records into the table approx 8 times slower (tested with fb 2.1 with ODS 11.0). PIO_init_data() makes file growth much faster. Now I need to do some more measurements with 2.0.Release and after it decide, how to backport.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

description: 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:
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.

=>

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.

environment: linux
possibly other posix platforms too

=>

Linux, possibly other POSIX platforms too

summary: On linux forced writes do not work. => Forced writes do not work on Linux

@firebird-automations
Copy link
Collaborator Author

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.
Do you have any information about this?

@firebird-automations
Copy link
Collaborator Author

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

There is interesting article in linux kernel tracker:
http://bugzilla.kernel.org/show_bug.cgi?id=5994

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.

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

Fix Version: 2.1 Beta 2 [ 10190 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 13152 ] => Firebird [ 15334 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Backported without serious performance optimization.
No idea how to do it safely without ODS 11.1 from firebird 2.1.

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.0.4 [ 10211 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Closed [ 6 ] => Closed [ 6 ]

QA Status: No test => Cannot be tested

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment