Re: Filesystem benchmarking for pg 8.3.3 server - Mailing list pgsql-performance

From Gregory Stark
Subject Re: Filesystem benchmarking for pg 8.3.3 server
Date
Msg-id 874p5jykpj.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Filesystem benchmarking for pg 8.3.3 server  (david@lang.hm)
Responses Re: Filesystem benchmarking for pg 8.3.3 server  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-performance
<david@lang.hm> 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!

pgsql-performance by date:

Previous
From: "Gurjeet Singh"
Date:
Subject: Re: Optimizing a VIEW
Next
From: Gregory Stark
Date:
Subject: Re: Filesystem benchmarking for pg 8.3.3 server