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