X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 106879FB28C for ; Tue, 15 Aug 2006 17:59:28 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 42903-05 for ; Tue, 15 Aug 2006 17:59:15 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by postgresql.org (Postfix) with ESMTP id 85AE59FB274 for ; Tue, 15 Aug 2006 17:59:16 -0300 (ADT) Received: from osgiliath.mathom.us ([72.66.19.42]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J42005OQ4YEL4X1@vms046.mailsrvcs.net> for pgsql-performance@postgresql.org; Tue, 15 Aug 2006 15:59:02 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by osgiliath.mathom.us (Postfix) with ESMTP id C1BA56E630; Tue, 15 Aug 2006 16:59:00 -0400 (EDT) Received: from osgiliath.mathom.us ([127.0.0.1]) by localhost (osgiliath.home.mathom.us [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CyjHcoeDkqU6; Tue, 15 Aug 2006 16:58:59 -0400 (EDT) Received: by osgiliath.mathom.us (Postfix, from userid 1000) id 428DA6FC71; Tue, 15 Aug 2006 16:58:59 -0400 (EDT) Date: Tue, 15 Aug 2006 16:58:59 -0400 From: Michael Stone Subject: Re: Postgresql Performance on an HP DL385 and In-reply-to: <20060815193951.GA13695@mark.mielke.cc> To: mark@mark.mielke.cc Cc: pgsql-performance@postgresql.org Mail-followup-to: mark@mark.mielke.cc, pgsql-performance@postgresql.org Message-id: <20060815205857.GY2900@mathom.us> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-disposition: inline X-Virus-Scanned: Debian amavisd-new at mathom.us X-Pgp-Fingerprint: 53 FF 38 00 E7 DD 0A 9C 84 52 84 C5 EE DF 7C 88 References: <20060810110935.GF2900@mathom.us> <20060814153841.GF27928@pervasive.com> <721b21dc0608140851v2332cdf9g59808004c983540f@mail.gmail.com> <20060814170545.GG27928@pervasive.com> <20060814170902.GN2900@mathom.us> <20060815162926.GS27928@pervasive.com> <20060815172645.GU2900@mathom.us> <20060815183327.GC12834@mark.mielke.cc> <20060815190254.GW2900@mathom.us> <20060815193951.GA13695@mark.mielke.cc> User-Agent: Mutt/1.5.12-2006-07-14 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.726 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO, SPF_PASS X-Spam-Level: X-Archive-Number: 200608/252 X-Sequence-Number: 20437 On Tue, Aug 15, 2006 at 03:39:51PM -0400, mark@mark.mielke.cc wrote: >No. This is not true. Updating the file system structure (inodes, indirect >blocks) touches a separate part of the disk than the actual data. If >the file system structure is modified, say, to extend a file to allow >it to contain more data, but the data itself is not written, then upon >a restore, with a system such as ext2, or ext3 with writeback, or xfs, >it is possible that the end of the file, even the postgres log file, >will contain a random block of data from the disk. If this random block >of data happens to look like a valid xlog block, it may be played back, >and the database corrupted. you're conflating a whole lot of different issues here. You're ignoring the fact that postgres preallocates the xlog segment, you're ignoring the fact that you can sync a directory entry, you're ignoring the fact that syncing some metadata (such as atime) doesn't matter (only the block allocation is important in this case, and the blocks are pre-allocated). >This is also wrong. fsck is needed because the file system is broken. nope, the file system *may* be broken. the dirty flag simply indicates that the filesystem needs to be checked to find out whether or not it is broken. >I don't mean to be offensive, but I won't accept what you say, as it does >not make sense with my understanding of how file systems work. :-) I'm not getting paid to convince you of anything. Mike Stone