From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
---|---|
To: | Ben Chobot <bench(at)silentmedia(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Maximum transaction rate |
Date: | 2009-03-13 18:59:56 |
Message-ID: | 1236970796.7023.73.camel@jd-laptop.pragmaticzealot.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 2009-03-13 at 11:41 -0700, Ben Chobot wrote:
> On Fri, 13 Mar 2009, Joshua D. Drake wrote:
>
> >> It seems to me that all you get with a BBU-enabled card is the ability to
> >> get burts of writes out of the OS faster. So you still have the problem,
> >> it's just less like to be encountered.
> >
> > A BBU controller is about more than that. It is also supposed to be
> > about data integrity. The ability to have unexpected outages and have
> > the drives stay consistent because the controller remembers the state
> > (if that is a reasonable way to put it).
>
> Of course. But if you can't reliably flush the OS buffers (because, say,
> you're using LVM so fsync() doesn't work), then you can't say what
> actually has made it to the safety of the raid card.
Wait, actually a good BBU RAID controller will disable the cache on the
drives. So everything that is cached is already on the controller vs.
the drives itself.
Or am I missing something?
Joshua D. Drake
>
--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997
From | Date | Subject | |
---|---|---|---|
Next Message | Christophe | 2009-03-13 19:09:20 | Re: Maximum transaction rate |
Previous Message | Joshua D. Drake | 2009-03-13 18:43:30 | Re: Maximum transaction rate |