Re: Excessive (and slow) fsync() within single transaction

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(at)vger(dot)kernel(dot)org/msg272253.html
[2] http://openquery.com/blog/host-flush
[3] http://forum.soft32.com/linux/flush-disk-write-cache-userspace-ftopict338477.html