Re: win32 performance - fsync question

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Evgeny Rodichev <er(at)sai(dot)msu(dot)su>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Magnus Hagander <mha(at)sollentuna(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: win32 performance - fsync question
Date: 2005-02-17 20:24:06
Message-ID: 4214FD66.2040307@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Evgeny Rodichev wrote:

> Write cache is enabled under Linux by default all the time I make deal
> with it (since 1993).
>
> It doesn't interfere with fsync(), as linux kernel uses cache flush for
> fsync.

The problem is that most IDE drives lie (or perhaps you could say the
specification is ambiguous) about completion of the cache-flush command
-- they say "Yeah, I've flushed" when they have not actually written the
data to the media and have no provision for making sure it will get
there in the event of power failure.

So Linux is indeed doing a cache flush on fsync, but the hardware is not
behaving as expected. By turning off the write-cache on the disk via
hdparm, you manage to get the hardware to behave better. The kernel is
caching anyway, so the loss of the drive's write cache doesn't make a
big difference.

There was some work done for better IDE write-barrier support (related
to TCQ/SATA support?) in the kernel, but I'm not sure how far that has
progressed.

-O

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2005-02-17 20:39:38 Re: win32 performance - fsync question
Previous Message Tom Lane 2005-02-17 20:15:39 Re: win32 performance - fsync question