| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | <david(at)lang(dot)hm> |
| Cc: | "Decibel!" <decibel(at)decibel(dot)org>, "Henrik" <henke(at)mac(dot)se>, "Jeff" <threshar(at)threshar(dot)is-a-geek(dot)com>, "Luke Lonergan" <LLonergan(at)greenplum(dot)com>, <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Filesystem benchmarking for pg 8.3.3 server |
| Date: | 2008-08-17 10:55:36 |
| Message-ID: | 874p5jykpj.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
<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.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2008-08-17 11:17:55 | Re: Filesystem benchmarking for pg 8.3.3 server |
| Previous Message | Gurjeet Singh | 2008-08-17 02:19:28 | Re: Optimizing a VIEW |