Re: Raid 10 chunksize
От | david@lang.hm |
---|---|
Тема | Re: Raid 10 chunksize |
Дата | |
Msg-id | alpine.DEB.1.10.0904011337310.28893@asgard.lang.hm обсуждение исходный текст |
Ответ на | Re: Raid 10 chunksize (Mark Kirkwood <markir@paradise.net.nz>) |
Ответы |
Re: Raid 10 chunksize
|
Список | 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 > > >
В списке pgsql-performance по дате отправления: