| From: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info>, Karl Denninger <karl(at)denninger(dot)net>, Laszlo Nagy <gandalf(at)shopzeus(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: SSD + RAID |
| Date: | 2009-11-30 00:46:33 |
| Message-ID: | 4B1315E9.50400@cheapcomplexdevices.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Bruce Momjian wrote:
> Greg Smith wrote:
>> A good test program that is a bit better at introducing and detecting
>> the write cache issue is described at
>> http://brad.livejournal.com/2116715.html
>
> Wow, I had not seen that tool before. I have added a link to it from
> our documentation, and also added a mention of our src/tools/fsync test
> tool to our docs.
One challenge with many of these test programs is that some
filesystem (ext3 is one) will flush drive caches on fsync()
*sometimes, but not always. If your test program happens to do
a sequence of commands that makes an fsync() actually flush a
disk's caches, it might mislead you if your actual application
has a different series of system calls.
For example, ext3 fsync() will issue write barrier commands
if the inode was modified; but not if the inode wasn't.
See test program here:
http://www.mail-archive.com/linux-kernel(at)vger(dot)kernel(dot)org/msg272253.html
and read two paragraphs further to see how touching
the inode makes ext3 fsync behave differently.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2009-11-30 03:09:45 | Re: SSD + RAID |
| Previous Message | Ing . Marcos Luís Ortíz Valmaseda | 2009-11-29 21:42:24 | Any have tested ZFS like PostgreSQL installation filesystem? |