pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Gregory Stark <stark@enterprisedb.com>
To: david@lang.hm
Cc: Decibel! <decibel@decibel.org>
Cc: Henrik <henke@mac.se>
Cc: Jeff <threshar@threshar.is-a-geek.com>
Cc: Luke Lonergan <LLonergan@greenplum.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Filesystem benchmarking for pg 8.3.3 server
Date: Sun, 17 Aug 2008 12:17:55 +0100
Message-ID: <87y72vx53w.fsf@oxford.xeocode.com> (raw)
In-Reply-To: <874p5jykpj.fsf@oxford.xeocode.com>
References: <014F2941B0A1EA47BD61D21526B806E903509704@MI8NYCMAIL08.Mi8.com>
	<F54DECFD-927B-4F64-B913-E8D903892435@mac.se>
	<alpine.DEB.1.10.0808081917080.4561@asgard.lang.hm>
	<AC012133-6932-46DD-A723-B2DCF98E5380@mac.se>
	<2DBD3E73-D9E5-4DFA-832F-3FD53480B284@torgo.978.org>
	<8795DFE4-BFE1-49A5-8341-A6823DF2BE4E@decibel.org>
	<32CD744F-2C1A-4BE2-B4BA-90CFD3A86DF7@mac.se>
	<04470CDD-146A-4725-BBC5-22E3271B958A@decibel.org>
	<alpine.DEB.1.10.0808161714280.12859@asgard.lang.hm>
	<874p5jykpj.fsf@oxford.xeocode.com>

"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!



view thread (41+ messages)

Message-ID: <87y72vx53w.fsf@oxford.xeocode.com>
Permalink:  ../87y72vx53w.fsf@oxford.xeocode.com/
Also on:    postgresql.org/message-id/87y72vx53w.fsf@oxford.xeocode.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: stark@enterprisedb.com, david@lang.hm, decibel@decibel.org, henke@mac.se, threshar@threshar.is-a-geek.com, LLonergan@greenplum.com
  Subject: Re: Filesystem benchmarking for pg 8.3.3 server
  In-Reply-To: <87y72vx53w.fsf@oxford.xeocode.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox