Re: Excessive (and slow) fsync() within single transaction - Mailing list pgsql-general

From Ron Mayer
Subject Re: Excessive (and slow) fsync() within single transaction
Date
Msg-id 4B20181C.70300@cheapcomplexdevices.com
Whole thread Raw
In response to Re: Excessive (and slow) fsync() within single transaction  (Scott Marlowe <scott.marlowe@gmail.com>)
Responses Re: Excessive (and slow) fsync() within single transaction  (Greg Smith <greg@2ndquadrant.com>)
Re: Excessive (and slow) fsync() within single transaction  (Scott Marlowe <scott.marlowe@gmail.com>)
List pgsql-general
Scott Marlowe wrote:
> Actually, it's usually the drives that lie about fsync, especially
> consumer grade (and some server grade) SATA / PATA drives are known
> for this.

I'm still looking for any evidence of any drive that lies.

Is there actually a drive which claims to support the
IDE "FLUSH_CACHE_EXT" feature (IDE command 0xEA) that doesn't?!?

You can see if your drive claims to - most this century do -
in Linux with "hdparm -I /dev/sdX" which should show FLUSH_CACHE_EXT
if the disk supports this extension.  And if your disk is using a
last-century IDE spec that predated that feature, I think your kernel
probably told you in the startup messages that your drive is
not so much lying, but obsolete and missing a feature.

Software on the other hand sucks at sending these commands.

Ext3 will only send the right IDE commands if the inode was
touched[1]. VirtualBox doesn't send them correctly[2].  I
hear LVM and MD raid can lose those events too.
Since so many layers don't send the right IDE commands to flush,
userspace utilities exist to send those commands[4].  I
sometimes wonder if postgres should add something like that.

But I still haven't found any drive that lies -- and only a couple
who's firmware openly admits not to support the feature.


[1] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg272253.html
[2] http://openquery.com/blog/host-flush
[3] http://forum.soft32.com/linux/flush-disk-write-cache-userspace-ftopict338477.html


pgsql-general by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: Excessive (and slow) fsync() within single transaction
Next
From: Scott Bailey
Date:
Subject: Re: [General] beginner!!!