| From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
|---|---|
| To: | "Greg Smith" <greg(at)2ndquadrant(dot)com> |
| Cc: | <jd(at)commandprompt(dot)com>,"Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Steve Crawford" <scrawford(at)pinpointresearch(dot)com>, <pgsql-performance(at)postgresql(dot)org>, "Ben Chobot" <bench(at)silentmedia(dot)com> |
| Subject: | Re: BBU Cache vs. spindles |
| Date: | 2010-10-21 18:54:03 |
| Message-ID: | 4CC045FB0200002500036C4B@gw.wicourts.gov |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance pgsql-www |
Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Kevin Grittner wrote:
>> So you're confident that an 8kB write to the controller will not
>> be done as a series of smaller atomic writes by the OS file
>> system?
>
> Sure, that happens. But if the BBU has gotten an fsync call after
> the 8K write, it shouldn't return success until after all 8K are
> in its cache.
I'm not concerned about an fsync after the controller has it; I'm
concerned about a system crash in the middle of writing an 8K page
to the controller. Other than the expected *size* of the window of
time during which you're vulnerable, what does a BBU caching
controller buy you in this regard? Can't the OS rearrange the
writes of disk sectors after the 8K page is written to the OS cache
so that the window might occasionally be rather large?
-Kevin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tim Goodaire | 2010-10-21 18:54:48 | Experiences with running PostgreSQL on Blue Arc Network Storage |
| Previous Message | Jesper Krogh | 2010-10-21 18:13:24 | Re: Slow count(*) again... |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2010-10-21 19:07:58 | Re: BBU Cache vs. spindles |
| Previous Message | Joshua Tolley | 2010-10-21 18:04:01 | Doc search fail |