> > > > * 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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
