Re: Raid 10 chunksize
От | Mark Kirkwood |
---|---|
Тема | Re: Raid 10 chunksize |
Дата | |
Msg-id | 49D31E85.8050405@paradise.net.nz обсуждение исходный текст |
Ответ на | Re: Raid 10 chunksize (Scott Carey <scott@richrelevance.com>) |
Ответы |
Re: Raid 10 chunksize
Re: Raid 10 chunksize |
Список | 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 по дате отправления: