Re: [pgsql-hackers-win32] win32 performance - fsync question

> > > > * Win32, with fsync, write-cache disabled: no data corruption
> > > > * Win32, with fsync, write-cache enabled: no data corruption
> > > > * Win32, with osync, write cache disabled: no data corruption
> > > > * Win32, with osync, write cache enabled: no data
> corruption. Once
> > > > I
> > > > got:
> > > > 2005-02-24 12:19:54 LOG: could not open file "C:/Program
> > > > Files/PostgreSQL/8.0/data/pg_xlog/000000010000000000000010"
> > > (log file
> > > > 0, segment 16): No such file or directory
> > > > but the data in the database was consistent.
> > >
> > > It disturbs me that you couldn't produce data corruption in the
> > > cases where it theoretically should occur. Seems like this is an
> > > indication that your test was insufficiently severe, or
> that there
> > > is something going on we don't understand.
> >
> > The Windows driver knows abotu the write cache, and at
> least fsync()
> > pushes through the write cache even if it's there. This seems to
> > indicate taht O_SYNC at least partiallyi does this as well. This is
> > why there is no performance difference at all on fsync() with write
> > cache on or off.
> >
> > I don't know if this is true for all IDE disks. COuld be
> that my disk
> > is particularly well-behaved.
>
> This indicated to me that open_sync did not require any
> additional changes than our current fsync.

fsync and open_sync both write through the write cache in the operating
system. Only fsync=off turns this off.

fsync also writes through the hardware write cache. o_sync does not.
This is what causes the large slowdown with write cache enabled,
*including* most battery backed write cache systems (pretty much making
the write-cache a waste of money). This may be a good thing on IDE
systems (for admins that don't know how to remove the little check in
the box for "enable write caching on the disk" that MS provides, which
*explicitly* warns that you may lose data if you enabled it), but it's a
very bad thing for anything higher end.

fsync also syncs the directory metadata. o_sync only cares about the
files contents. (This is what causes the large slowdown with write cache
*disabled*, becuase it requires multiple writes on multiple disk
locations for each fsync).

Basically, fsync hurts people who configure their box correctly, or who
use things like SCSI disks. o_sync hurts people who configure their
machine in an unsafe way.

//Magnus