Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id BC71A9FA162 for ; Thu, 14 Dec 2006 13:47:15 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-new, port 10024) with ESMTP id 15927-01 for ; Thu, 14 Dec 2006 13:47:11 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from wolff.to (wolff.to [66.93.197.194]) by postgresql.org (Postfix) with SMTP id 0054B9F9FDA for ; Thu, 14 Dec 2006 13:47:11 -0400 (AST) Received: (qmail 27689 invoked by uid 500); 14 Dec 2006 17:48:09 -0000 Date: Thu, 14 Dec 2006 11:48:09 -0600 From: Bruno Wolff III To: Jim Nasby Cc: Mark Lewis , Brian Wipf , pgsql-performance@postgresql.org Subject: Re: File Systems Compared Message-ID: <20061214174809.GA26057@wolff.to> Mail-Followup-To: Bruno Wolff III , Jim Nasby , Mark Lewis , Brian Wipf , pgsql-performance@postgresql.org References: <82bqmh3rfc.fsf@mid.bfk.de> <1165424114.9734.298.camel@archimedes> <20061211175411.GA3236@wolff.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/380 X-Sequence-Number: 22436 On Thu, Dec 14, 2006 at 01:39:00 -0500, Jim Nasby wrote: > On Dec 11, 2006, at 12:54 PM, Bruno Wolff III wrote: > > > >This appears to be changing under Linux. Recent kernels have write > >barriers > >implemented using cache flush commands (which some drives ignore, > >so you > >need to be careful). In very recent kernels, software raid using > >raid 1 > >will also handle write barriers. To get this feature, you are > >supposed to > >mount ext3 file systems with the barrier=1 option. For other file > >systems, > >the parameter may need to be different. > > But would that actually provide a meaningful benefit? When you > COMMIT, the WAL data must hit non-volatile storage of some kind, > which without a BBU or something similar, means hitting the platter. > So I don't see how enabling the disk cache will help, unless of > course it's ignoring fsync. When you do an fsync, the OS sends a cache flush command to the drive, which on most drives (but supposedly there are ones that ignore this command) doesn't return until all of the cached pages have been written to the platter, and doesn't return from the fsync until the flush is complete. While this writes more sectors than you really need, it is safe. And it allows for caching to speed up some things (though not as much as having queued commands would). I have done some tests on my systems and the speeds I am getting make it clear that write barriers slow things down to about the same range as having caches disabled. So I believe that it is likely working as advertised. Note the use case for this is more for hobbiests or development boxes. You can only use it on software raid (md) 1, which rules out most "real" systems.