Issue Details (XML | Word | Printable)

Key: DOC-104
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Norman Dunbar
Reporter: Коренберг Марк
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

gfix -write sync documentation is wrong

Created: 25/Feb/15 06:49 AM   Updated: 13/Feb/18 08:07 PM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Environment: Firebird 2.5

 Description  « Hide

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.)

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 25/Feb/15 08:33 PM
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.

Norman Dunbar added a comment - 13/Feb/18 05:50 PM
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.


Norman Dunbar added a comment - 13/Feb/18 08:07 PM
The manual has been updated and will be uploaded ASAP.