From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
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 03:09:45 |
Message-ID: | 200911300309.nAU39j318088@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Ron Mayer wrote:
> 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.
I thought our only problem was testing the I/O subsystem --- I never
suspected the file system might lie too. That email indicates that a
large percentage of our install base is running on unreliable file
systems --- why have I not heard about this before? Do the write
barriers allow data loss but prevent data inconsistency? It sound like
they are effectively running with synchronous_commit = off.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2009-11-30 05:12:41 | Re: SSD + RAID |
Previous Message | Ron Mayer | 2009-11-30 00:46:33 | Re: SSD + RAID |