| From: | James Mansion <james(at)mansionfamily(dot)plus(dot)com> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Greg Smith <greg(at)2ndquadrant(dot)com>, jd(at)commandprompt(dot)com, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, 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-24 08:05:19 |
| Message-ID: | 4CC3E8BF.4090409@mansionfamily.plus.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance pgsql-www |
Kevin Grittner wrote:
> On what do you base that assumption? I assume that we send a full
> 8K to the OS cache, and the file system writes disk sectors
> according to its own algorithm. With either platters or BBU cache,
> the data is persisted on fsync; why do you see a risk with one but
> not the other?
>
Surely 'the data is persisted sometime after our write and before the
fsynch returns, but
may be written:
- in small chunks
- out of order
- in an unpredictable way'
When I looked at the internals of TokyoCabinet for example, the design
was flawed but
would be 'fairly robust' so long as mmap'd pages that were dirtied did
not get persisted
until msync, and were then persisted atomically.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2010-10-24 16:53:13 | Re: BBU Cache vs. spindles |
| Previous Message | Josh Berkus | 2010-10-23 21:03:06 | Re: BBU Cache vs. spindles |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2010-10-24 16:53:13 | Re: BBU Cache vs. spindles |
| Previous Message | Josh Berkus | 2010-10-23 21:03:06 | Re: BBU Cache vs. spindles |