Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 27A38635819 for ; Fri, 3 Apr 2009 07:30:20 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 83554-10 for ; Fri, 3 Apr 2009 07:30:11 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from westnet.com (westnet.com [216.187.52.2]) by mail.postgresql.org (Postfix) with ESMTP id D36F2635572 for ; Fri, 3 Apr 2009 07:30:16 -0300 (ADT) Received: from westnet.com (localhost [127.0.0.1]) by westnet.com (8.14.0/8.14.0) with ESMTP id n33AUCai012902; Fri, 3 Apr 2009 06:30:12 -0400 (EDT) Received: from localhost (gsmith@localhost) by westnet.com (8.14.0/8.13.2/Submit) with ESMTP id n33AUCJv012899; Fri, 3 Apr 2009 06:30:12 -0400 (EDT) X-Authentication-Warning: westnet.com: gsmith owned process doing -bs Date: Fri, 3 Apr 2009 06:30:12 -0400 (EDT) From: Greg Smith X-X-Sender: gsmith@westnet.com To: Scott Carey cc: Stef Telford , Mark Kirkwood , "pgsql-performance@postgresql.org" Subject: Re: Raid 10 chunksize In-Reply-To: Message-ID: References: User-Agent: Alpine 2.01 (GSO 1184 2008-12-16) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=AWL=0.000 X-Spam-Level: X-Archive-Number: 200904/56 X-Sequence-Number: 33423 On Thu, 2 Apr 2009, Scott Carey wrote: > The big one, is this quote from the linux kernel list: > " Right now, if you want a reliable database on Linux, you _cannot_ > properly depend on fsync() or fdatasync(). Considering how much Linux > is used for critical databases, using these functions, this amazes me. > " Things aren't as bad as that out of context quote makes them seem. There are two main problem situations here: 1) You cannot trust Linux to flush data to a hard drive's write cache. Solution: turn off the write cache. Given the general poor state of targeted fsync on Linux (quoting from a downthread comment by David Lang: "in data=ordered mode, the default for most distros, ext3 can end up having to write all pending data when you do a fsync on one file"), those fsyncs were likely to blow out the drive cache anyway. 2) There are no hard guarantees about write ordering at the disk level; if you write blocks ABC and then fsync, you might actually get, say, only B written before power goes out. I don't believe the PostgreSQL WAL design will be corrupted by this particular situation, because until that fsync comes back saying all 3 are done none of them are relied upon. > Interestingly, postgres would be safer on linux if it used > sync_file_range instead of fsync() but that has other drawbacks and > limitations I have thought about whether it would be possible to add a Linux-specific improvement here into the code path that does something custom in this area for Windows/Mac OS X when you use fsync_method=fsync_writethrough We really should update the documentation in this area before 8.4 ships. I'm looking into moving the "Tuning PostgreSQL WAL Synchronization" paper I wrote onto the wiki and then fleshing it out with all this filesystem-specific trivia. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD