> 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

Fri, 9 Mar 2001 14:49:38 -0800 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: AW: AW: AW: WAL does not recover gracefully from ou
	t-of -dis k-sp ace