Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 612282E0168 for ; Sat, 1 Mar 2008 14:11:28 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 61709-09 for ; Sat, 1 Mar 2008 14:11:23 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 3A00B2E0166 for ; Sat, 1 Mar 2008 14:11:25 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m21IBKYO029629; Sat, 1 Mar 2008 13:11:21 -0500 (EST) To: "Scott Marlowe" cc: "Franck Routier" , pgsql-performance Subject: Re: 12 disks raid setup In-reply-to: References: <1204285894.11773.33.camel@franck-gusty> <1204296705.11773.51.camel@franck-gusty> <47C8A6D9.1050502@Sheeky.Biz> <1204367277.9116.16.camel@franck-gusty> Comments: In-reply-to "Scott Marlowe" message dated "Sat, 01 Mar 2008 06:44:13 -0600" Date: Sat, 01 Mar 2008 13:11:20 -0500 Message-ID: <29628.1204395080@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/4 X-Sequence-Number: 28958 "Scott Marlowe" writes: > On Sat, Mar 1, 2008 at 4:27 AM, Franck Routier wrote: >> Well, am I just wrong, or the file system might also heavily rely on >> cache, especially as I use XFS ? >> >> So anyway Postgresql has no way to know if the data is really on the >> disk, and in case of a brutal outage, the system may definitely lose >> data, wether there is another level of caching (Raid controller) or >> not... > nope. assuming your disk subsystem doesn't lie about write > completion, then postgresql can recover from complete and sudden loss > of power without any data loss. Franck does have a point here: we are expecting the filesystem to tend to its own knitting. If a power failure corrupts the filesystem so badly that we can't find the WAL files, or their contents are badly scrambled, then we're screwed. Most modern filesystems defend themselves against that using journaling, which is exactly the same idea as WAL but applied to filesystem metadata. We do expect that when we fsync a file, by the time the OS reports that that's done both the file contents and its metadata are safely on disk. This is part of the specification for fsync, so the OS is clearly broken if it doesn't get that right. Whether the OS *can* guarantee it if the disk drive lies about write completion is something you'd have to ask the filesystem hackers about. regards, tom lane