> $ gcc -Wall -O -DINIT_WRITE tfsync.c
> $ time a.out
>
> real1m15.11s
> user0m0.04s
> sys 0m32.76s
>
> Note the large amount of system time here, and the fact that the extra
> time in INIT_WRITE is all system time. I have previously
> observed that fsync() on HPUX 10.20 appears to
> 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
Tom Lane <[EMAIL PROTECTED]> writes:
> We just bought back almost all the system time. The only possible
> explanation is that this way either doesn't keep the buffers from prior
> blocks, or does not scan them for dirtybits. I note that the open(2)
> man page is phrased so that O_SYNC is actua
> >> This seems odd. As near as I can tell, O_SYNC is simply a command to do
> >> fsync implicitly during each write call. It cannot save any I/O unless
> >> I'm missing something significant. Where is the performance difference
> >> coming from?
>
> > Yes, odd, but sure very reproducible her
> > > Of course we would need to buffer >= 1 xlog page before write (or commit)
> > > to gain the full advantage.
> >
> > > prewrite 0 + write and fsync: 60.4 sec
> > > sparse file + write with O_SYNC: 37.5 sec
> > > no prewrite + write with O_SYNC: 36.8 sec
> > > p
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> This seems odd. As near as I can tell, O_SYNC is simply a command to do
>> fsync implicitly during each write call. It cannot save any I/O unless
>> I'm missing something significant. Where is the performance difference
>> coming from?
> Y
> > A short test shows, that opening the file O_SYNC, and thus avoiding fsync()
> > would cut the effective time needed to sync write the xlog more than in half.
> > Of course we would need to buffer >= 1 xlog page before write (or commit)
> > to gain the full advantage.
>
> > prewrite 0 + write
