Thread: RE: AW: AW: AW: WAL does not recover gracefully from ou t-of -dis k-sp ace
RE: AW: AW: AW: WAL does not recover gracefully from ou t-of -dis k-sp ace
From
"Mikheev, Vadim"
Date:
> 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