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

Ron Mayer wrote:
> 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 seem to think that a "lying drive" is one that doesn't flush its
cache when you ask it to. That's not the definition, and as you point
out it's rare behavior--some crappy drives would do this many years ago
when the drive flush was a new thing, nowadays that's unheard of.

But back in the day, when you wrote to a drive, it never returned
success until that write was done. Anything that doesn't have that
behavior was considered a "lying drive". It was something that consumer
drives did but "enterprise" ones didn't.

Nowadays, most drives do this, and the various cache flush calls allow
one to work around it. But the drives still "lie" from some viewpoints,
simply because the write calls don't wait for completion before
returning success, the original criteria. If you're naive and believe
that anything the drive has said is written is actually on disk, which
used to be how things worked, from that perspective all (well, almost
all) drives lie. Having that behavior documented and a workaround
available doesn't change that.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com