If I recall correctly, this absolutely killed FreeBSD in benchmarks while Linux looked amazing. I recall the editors having to put a note in there saying that Linux wasn't committing I/O but FreeBSD was to explain the huge difference. At least I think this is the situation I'm remembering. Hmm..

The fsync vs I/O errors bug didn't have any performance impact in absence of failing disks, it was about what happened when you tried to fsync again after your storage stack reported a write error.

But for a OS that has a bad fsync, have a look at macOS - they even document that it doesn't commit data to stable storage and you should use some other system call to do it: https://developer.apple.com/library/archive/documentation/Sy...

(A web search now only finds iOS man pages, but the fsync caveat was the same in OS X/Darwin manpages before they were taken offline)

> This was a Linux fsync implementation issue.

No, since most OS had (and still have) the "incorrect" behaviour. This was (and still is!) a generalised issue of fsync itself, since the state of buffers is undefined in case of failure.

The assumption that you could retry fsync on error was always effectively incorrect, per the posgres wiki on the subject openbsd, netbsd, and macos had essentially the same behaviour (invalidate buffers on failure). FreeBSD diverged from the rest because they rewrote brelse() long after separating from the others.

After this issue surfaced, openbsd updated their implementation to ensure the call would always fail, but only if the file is kept open which had not been guaranteed for postgres (don't know if it now is).

Linux had (has?) the additional issue of wonky error reporting, but that would not save your ass.