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 87y72vx53w.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Filesystem benchmarking for pg 8.3.3 server  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-performance
"Gregory Stark" <stark@enterprisedb.com> writes:

> <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.

Or now that I think about it, replace two or more blocks from the same set of
parity bits. It only has to recalculate the parity bits once for all those
blocks instead of for every single block write.


--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's PostGIS support!

pgsql-performance by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Filesystem benchmarking for pg 8.3.3 server
Next
From: Madison Kelly
Date:
Subject: Re: Optimizing a VIEW