Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 7A3219FA469 for ; Mon, 13 Nov 2006 05:01:41 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 04744-07 for ; Mon, 13 Nov 2006 09:01:38 +0000 (UTC) X-Greylist: delayed 00:29:15.24901 by SQLgrey- Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id 07F289FA26D for ; Mon, 13 Nov 2006 05:01:12 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.3 Received: from mail.esphion.com (serv-0.esphion.com [202.55.97.148]) by svr4.postgresql.org (Postfix) with ESMTP id 444FE5AF880 for ; Mon, 13 Nov 2006 08:32:20 +0000 (GMT) Received: from [10.0.1.181] (helo=conker.alb-nz.esphion.com) by mail.esphion.com with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1GjXEd-0001SD-3d; Mon, 13 Nov 2006 21:32:08 +1300 Received: from guy by conker.alb-nz.esphion.com with local (Exim 4.50) id 1GjXEb-0003u3-QV; Mon, 13 Nov 2006 21:32:05 +1300 Date: Mon, 13 Nov 2006 21:32:05 +1300 From: Guy Thornley To: Ron Mayer Cc: toby , pgsql-performance@postgresql.org Subject: Re: Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?] Message-ID: <20061113083205.GJ29915@esphion.com> Reply-To: Guy Thornley References: <1162920135.543539.118390@h54g2000cwb.googlegroups.com> <2cl4h.1236$Es5.713@trnddc07> <1162995009.842121.125840@k70g2000cwa.googlegroups.com> <1163016362.882752.14140@m7g2000cwm.googlegroups.com> <06E4h.5421$Lt4.2413@trnddc08> <1163084338.373159.99280@h54g2000cwb.googlegroups.com> <1163171668.837184.161080@e3g2000cwe.googlegroups.com> <4554CAC9.3000104@cheapcomplexdevices.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4554CAC9.3000104@cheapcomplexdevices.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200611/98 X-Sequence-Number: 21868 > > That's not quite what I meant by "trust". Some drives lie about the > > flush. > > Is that really true, or a misdiagnosed software bug? I've yet to find a drive that lies about write completion. (*) The problem is that the drives boot-up default is write-caching enabled (or perhaps the system BIOS sets it that way). If you turn an IDE disks write cache off explicity, using hdparm or similar, they behave. The problem, I think, is a bug in hdparm or the linux kernel: if you use the little-'i' option, the output indicates the WC is disabled. However, if you use big-'I' to actually interrogate the drive, you get the correct setting. I tested this a while ago by writing a program that did fsync() to test write latency and random-reads to test read latency, and then comparing them. - Guy * I did experience a too-close-to-call case, where after write-cache was disabled, the write latency was the same as the read latency. For every other drive the write latency much, MUCH higher. However, before I disabled the WC, the write latency was a fraction of the read latency.