Re: Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Lane wrote:

| Gaetano Mendola <mendola(at)bigfoot(dot)com> writes:
|
|>Now that the argument is already open, why postgres choose
|>on linux fdatasync? I'm understanding from other posts that
|>on this platform open_sync is better than fdatasync.
|
|
| AFAIR, we've seen *one* test from *one* person alleging that.
| And it was definitely not that way when we tested the behavior
| originally, several releases back. I'd like to see more evidence,
| or better some indication that the Linux kernel changed algorithms,
| before changing the default.

I remember more then one person claim that open_sync *apparently*
was working better then fdatasync, however I trust you ( here is
3:00 AM ).

| The tests that started this thread are pretty unconvincing in my eyes,
| because they are comparing open_sync against code that fsyncs after each
| one-block write. Under those circumstances, *of course* fsync will lose
| (or at least do no better), because it's forcing the same number of
| writes through a same-or-less-efficient API.
|
| The reason that this isn't a trivial choice is that Postgres doesn't
| necessarily need to fsync after every block of WAL. In particular,
| when doing large transactions there could be many blocks written between
| fsyncs, and in that case you could come out ahead with fsync because the
| kernel would have more freedom to schedule disk writes.

Are you suggesting that postgres shall use more the one sync method and use
one or the other depending on the activity is performing ?

| So, the only test I put a whole lot of faith in is testing your own
| workload on your own Postgres server. But if we want to set up a toy
| test program to test this stuff, it's at least got to have an easily
| adjustable (and preferably randomizable) distance between fsyncs.
|
| Also, tests on IDE drives have zero credibility to start with, unless
| you can convince me you know how to turn off write buffering on the
| drive...

I reported the IDE times just for info; however my SAN works better
with open_sync. Can we trust on numbers given by tools/fsync ? I seen
some your objections in the past but I don't know if there was some fix
from that time.

Regards
Gaetano Mendola

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBRkvW7UpzwH2SGd4RAia1AKD2L5JLhpRNvBzPq9Lv5bAfFJvRmwCffjC5
hg7V0Sfm2At7yR1C+gBCzPE=
=RsSy
-----END PGP SIGNATURE-----