Skip site navigation (1) Skip section navigation (2)

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

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>,"Michael Paesold" <mpaesold(at)gmx(dot)at>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>,<pgsql-hackers-win32(at)postgresql(dot)org>,"Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
Subject: Re: [pgsql-hackers-win32] win32 performance - fsync question
Date: 2005-03-17 09:05:39
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE6C70BD@algol.sollentuna.se (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-hackers-win32pgsql-patches
> > > > * 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

Responses

pgsql-hackers by date

Next:From: Dave PageDate: 2005-03-17 09:05:41
Subject: Re: Changing the default wal_sync_method to open_sync for Win32?
Previous:From: Magnus HaganderDate: 2005-03-17 08:44:59
Subject: Re: Changing the default wal_sync_method to open_sync for Win32?

pgsql-patches by date

Next:From: Simon RiggsDate: 2005-03-17 09:13:50
Subject: Re: read-only database
Previous:From: Neil ConwayDate: 2005-03-17 06:41:23
Subject: refactor preprocess_targetlist

pgsql-hackers-win32 by date

Next:From: Dave PageDate: 2005-03-17 09:05:41
Subject: Re: Changing the default wal_sync_method to open_sync for Win32?
Previous:From: Magnus HaganderDate: 2005-03-17 08:44:59
Subject: Re: Changing the default wal_sync_method to open_sync for Win32?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group