Re: Filesystem benchmarking for pg 8.3.3 server

"Gregory Stark" <stark(at)enterprisedb(dot)com> writes:

> <david(at)lang(dot)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!