Re: Filesystem benchmarking for pg 8.3.3 server
От | Gregory Stark |
---|---|
Тема | Re: Filesystem benchmarking for pg 8.3.3 server |
Дата | |
Msg-id | 874p5jykpj.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Filesystem benchmarking for pg 8.3.3 server (david@lang.hm) |
Ответы |
Re: Filesystem benchmarking for pg 8.3.3 server
|
Список | 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 по дате отправления: