Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 0C15E64FCC7 for ; Sun, 17 Aug 2008 07:55:46 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 80772-08 for ; Sun, 17 Aug 2008 07:55:39 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from oxford.xeocode.com (87-127-95-198.no-dns-yet.enta.net [87.127.95.198]) by postgresql.org (Postfix) with ESMTP id 7676664FCC1 for ; Sun, 17 Aug 2008 07:55:43 -0300 (ADT) Received: from localhost ([127.0.0.1] helo=oxford.xeocode.com) by oxford.xeocode.com with esmtp (Exim 4.69) (envelope-from ) id 1KUfv6-0001ad-HY; Sun, 17 Aug 2008 11:55:36 +0100 To: Cc: "Decibel!" , "Henrik" , "Jeff" , "Luke Lonergan" , Subject: Re: Filesystem benchmarking for pg 8.3.3 server In-Reply-To: (david@lang.hm's message of "Sat\, 16 Aug 2008 17\:15\:41 -0700 \(PDT\)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+mail01.enterprisedb.com:INBOX.performance" 6544) References: <014F2941B0A1EA47BD61D21526B806E903509704@MI8NYCMAIL08.Mi8.com> <2DBD3E73-D9E5-4DFA-832F-3FD53480B284@torgo.978.org> <8795DFE4-BFE1-49A5-8341-A6823DF2BE4E@decibel.org> <32CD744F-2C1A-4BE2-B4BA-90CFD3A86DF7@mac.se> <04470CDD-146A-4725-BBC5-22E3271B958A@decibel.org> From: Gregory Stark Organization: EnterpriseDB Date: Sun, 17 Aug 2008 11:55:36 +0100 Message-ID: <874p5jykpj.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.1 tagged_above=0 required=5 tests=RDNS_DYNAMIC=0.1 X-Spam-Level: X-Archive-Number: 200808/184 X-Sequence-Number: 31065 writes: >> If you are completely over-writing an entire stripe, there's no reason to >> read the existing data; you would just calculate the parity information from >> the new data. Any good controller should take that approach. > > in theory yes, in practice the OS writes usually aren't that large and aligned, > and as a result most raid controllers (and software) don't have the > special-case code to deal with it. I'm pretty sure all half-decent controllers and software do actually. This is one major reason that large (hopefully battery backed) caches help RAID-5 disproportionately. The larger the cache the more likely it'll be able to wait until the entire raid stripe is replaced avoid having to read in the old parity. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!