Re: Raid 10 chunksize

david@lang.hm

From: david@lang.hm
To: Mark Kirkwood <markir@paradise.net.nz>
Cc: Scott Carey <scott@richrelevance.com>, Stef Telford <stef@ummon.com>, "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Date: 2009-04-01T20:38:34Z
Lists: pgsql-performance
On Wed, 1 Apr 2009, Mark Kirkwood wrote:

> Scott Carey wrote:
>> 
>> A little extra info here >>  md, LVM, and some other tools do not allow the
>> file system to use write barriers properly.... So those are on the bad list
>> for data integrity with SAS or SATA write caches without battery back-up.
>> However, this is NOT an issue on the postgres data partition.  Data fsync
>> still works fine, its the file system journal that might have out-of-order
>> writes.  For xlogs, write barriers are not important, only fsync() not
>> lying.
>> 
>> As an additional note, ext4 uses checksums per block in the journal, so it
>> is resistant to out of order writes causing trouble.  The test compared to
>> here was on ext4, and most likely the speed increase is partly due to that.
>>
>> 
>
> [Looks at  Stef's  config - 2x 7200 rpm SATA RAID 0]  I'm still highly 
> suspicious of such a system being capable of outperforming one with the same 
> number of (effective) - much faster - disks *plus* a dedicated WAL disk 
> pair... unless it is being a little loose about fsync! I'm happy to believe 
> ext4 is better than ext3 - but not that much!

given how _horrible_ ext3 is with fsync, I can belive it more easily with 
fsync turned on than with it off.

David Lang

> However, its great to have so many different results to compare against!
>
> Cheers
>
> Mark
>
>
>