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

gfix -write sync documentation is wrong [DOC104] #113

Closed
firebird-automations opened this issue Feb 25, 2015 · 7 comments
Closed

gfix -write sync documentation is wrong [DOC104] #113

firebird-automations opened this issue Feb 25, 2015 · 7 comments

Comments

@firebird-automations
Copy link

Submitted by: Коренберг Марк (socketpair)

http://www.firebirdsql.org/manual/gfix-sync.html

gfix -write sync states that: "sync - data is written synchronously. This means that data is flushed to disc on COMMIT."

THIS IS WRONG, since in current implemetation (FB 2.5 in Linux) it just opens file using O_SYNC. This mean that every write is synchronous. Not only at COMMIT. So this is major performance loss.

So, what I want:
1. Fix documentation and say, that "gfix -write sync" will synchronously wait for every write fo file.
(Also, I'm not sure it is the same as forcedwrites=ON)
2. Add to documentation something like this:
"""
In order to bring performance/integrity to reasonable state, you may do that:
gfix -write async
Forced writes=off
MaxUnflushedWrites = 0
MaxUnflushedWriteTime = -1
"""
(As far as I see in strace, it issues fsync() at every commit at least.)

@firebird-automations
Copy link
Author

Modified by: Коренберг Марк (socketpair)

description: http://www.firebirdsql.org/manual/gfix-sync.html

gfix -write sync states that: "sync - data is written synchronously. This means that data is flushed to disc on COMMIT."

THIS IS WRONG, since in current implemetation (FB 2.5 in Linux) it just opens file using O_SYNC. This mean that every write is synchronous. Not only at COMMIT. So this is major performance loss.

In order to bring performance/integrity to reasonable state, you may do that:

So, what I want:
1. Fix documentation and say, that "gfix -write sync" will synchronously wait for every write fo file.
(Also, I'm not sure it is the same as forcedwrites=ON)
2. Add to documentation:
"""
gfix -write async
Forced writes=off
MaxUnflushedWrites = 0
MaxUnflushedWriteTime = -1
"""
(As far as I see in strace, it issues fsync() at every commit at least.)

=>

http://www.firebirdsql.org/manual/gfix-sync.html

gfix -write sync states that: "sync - data is written synchronously. This means that data is flushed to disc on COMMIT."

THIS IS WRONG, since in current implemetation (FB 2.5 in Linux) it just opens file using O_SYNC. This mean that every write is synchronous. Not only at COMMIT. So this is major performance loss.

So, what I want:
1. Fix documentation and say, that "gfix -write sync" will synchronously wait for every write fo file.
(Also, I'm not sure it is the same as forcedwrites=ON)
2. Add to documentation something like this:
"""
In order to bring performance/integrity to reasonable state, you may do that:
gfix -write async
Forced writes=off
MaxUnflushedWrites = 0
MaxUnflushedWriteTime = -1
"""
(As far as I see in strace, it issues fsync() at every commit at least.)

@firebird-automations
Copy link
Author

Modified by: @dyemanov

Project: Web site [ 10007 ] => Documentation [ 10005 ]

assignee: Alexey Kovyazin [ alexey.kovyazin ] => Paul Vinkenoog [ paulvink ]

Key: WEB131 => DOC104

@firebird-automations
Copy link
Author

Commented by: @dyemanov

I'd say that documentation is basically correct, because writes are usually performed at commit time (they're cached before that point). This gets incorrect only when we come to cache overflows or concurrent modifications in CS/SC.

And I'd avoid suggesting to use async writes, even with MaxUnflushedWrites = 0. This is just not reliable. FW is enabled by default intentionally in order to avoid disasters. Those who need better performance are free to tune their configs as they wish.

@firebird-automations
Copy link
Author

Modified by: @paulvink

assignee: Paul Vinkenoog [ paulvink ] => Norman Dunbar [ normandunbar ]

@firebird-automations
Copy link
Author

Commented by: @NormanDunbar

First of all, apologies for the lateness of my reply. I was on holiday when thie issue was assigned to me and completely forgot on my return.

Looking at Dmitry's comments, I don't think there is a need to update the documentation for this problem, and that we can close the issue?

I'll amend the docs is strictly necessary of course, but it's not looking like it is, at the moment.

Cheers,
Norm.

@firebird-automations
Copy link
Author

Commented by: @NormanDunbar

The manual has been updated and will be uploaded ASAP.

@firebird-automations
Copy link
Author

Modified by: @NormanDunbar

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

resolution: Fixed [ 1 ]

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

No branches or pull requests

2 participants