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
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 |