Re: Raid 10 chunksize - Mailing list pgsql-performance

From Mark Kirkwood
Subject Re: Raid 10 chunksize
Date
Msg-id 49D31E85.8050405@paradise.net.nz
Whole thread Raw
In response to Re: Raid 10 chunksize  (Scott Carey <scott@richrelevance.com>)
Responses Re: Raid 10 chunksize  (Stef Telford <stef@ummon.com>)
Re: Raid 10 chunksize  (david@lang.hm)
List pgsql-performance
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!

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

Cheers

Mark


pgsql-performance by date:

Previous
From: Greg Smith
Date:
Subject: Re: Strange behavior: pgbench and new Linux kernels
Next
From: Mark Kirkwood
Date:
Subject: Re: Raid 10 chunksize