> I tried this on HPUX 10.20, which has not only O_SYNC but also O_DSYNC
> (defined to do the equivalent of fdatasync()), and got truly
> fascinating results. Apparently, on this platform these flags change
> the kernel's buffering behavior! Observe:
Solaris 2.6 fascinates even more!!!
> $ gcc -Wall -O -DINIT_WRITE -DUSE_ODSYNC tfsync.c
> $ time a.out
>
> real 0m21.40s
> user 0m0.02s
> sys 0m0.60s
bash-2.02# gcc -Wall -O -DINIT_WRITE -DUSE_ODSYNC tfsync.c
bash-2.02# time a.out
real 0m4.242s
user 0m0.000s
sys 0m0.450s
It's hard to believe... Writing with DSYNC takes the same time as
file initialization - ~2 sec.
Also, there is no difference if using 64k blocks.
INIT_WRITE + OSYNC gives 52 sec for 8k blocks and 5.7 sec
for 256k ones, but INIT_WRITE + DSYNC doesn't depend on block
size.
Modern IDE drive? -:))
Probably we should change code to use O_DSYNC if defined even without
changing XLogWrite to write more than 1 block at once (if requested)?
As for O_SYNC:
bash-2.02# gcc -Wall -O -DINIT_WRITE tfsync.c
bash-2.02# time a.out
real 0m54.786s
user 0m0.010s
sys 0m10.820s
bash-2.02# gcc -Wall -O -DINIT_WRITE -DUSE_OSYNC tfsync.c
bash-2.02# time a.out
real 0m52.406s
user 0m0.020s
sys 0m0.650s
Not big win. Solaris has more optimized search for dirty blocks
than Tom' HP and Andreas' platform?
Vadim