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

[Greg Smith <greg@xxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxx  www.2ndQuadrant.com