pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Ron Mayer <rm_pg@cheapcomplexdevices.com>
To: Greg Smith <gsmith@gregsmith.com>
Cc: Henrik <henke@mac.se>
Cc: pgsql-performance@postgresql.org
Subject: Re: Filesystem benchmarking for pg 8.3.3 server
Date: Tue, 12 Aug 2008 14:47:57 -0700
Message-ID: <48A2050D.4050803@cheapcomplexdevices.com> (raw)
In-Reply-To: <Pine.GSO.4.64.0808081835320.21924@westnet.com>
References: <32A7A76B-16CA-4CDB-AD43-973AD6A3FC7B@mac.se>
	<Pine.GSO.4.64.0808081835320.21924@westnet.com>

Greg Smith wrote:
> some write cache in the SATA disks...Since all non-battery backed caches 
> need to get turned  off for reliable database use, you might want to  
> double-check that on the controller that's driving the SATA disks.

Is this really true?

Doesn't the ATA "FLUSH CACHE" command (say, ATA command 0xE7)
guarantee that writes are on the media?

http://www.t13.org/Documents/UploadedDocuments/technical/e01126r0.pdf
"A non-error completion of the command indicates that all cached data
  since the last FLUSH CACHE command completion was successfully written
  to media, including any cached data that may have been
  written prior to receipt of FLUSH CACHE command."
(I still can't find any $0 SATA specs; but I imagine the final
wording for the command is similar to the wording in the proposal
for the command which can be found on the ATA Technical Committee's
web site at the link above.)

Really old software (notably 2.4 linux kernels) didn't send
cache synchronizing commands for SCSI nor either ATA; but
it seems well thought through in the 2.6 kernels as described
in the Linux kernel documentation.
http://www.mjmwired.net/kernel/Documentation/block/barrier.txt

If you do have a disk where you need to disable write caches,
I'd love to know the name of the disk and see the output of
of "hdparm -I /dev/sd***" to see if it claims to support such
cache flushes.


I'm almost tempted to say that if you find yourself having to disable
caches on modern (this century) hardware and software, you're probably
covering up a more serious issue with your system.




view thread (41+ messages)  latest in thread

Message-ID: <48A2050D.4050803@cheapcomplexdevices.com>
Permalink:  ../48A2050D.4050803@cheapcomplexdevices.com/
Also on:    postgresql.org/message-id/48A2050D.4050803@cheapcomplexdevices.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: rm_pg@cheapcomplexdevices.com, gsmith@gregsmith.com, henke@mac.se
  Subject: Re: Filesystem benchmarking for pg 8.3.3 server
  In-Reply-To: <48A2050D.4050803@cheapcomplexdevices.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox