| From: | "Jeffrey Baker" <jwbaker(at)gmail(dot)com> |
|---|---|
| To: | "Bruce Momjian" <bruce(at)momjian(dot)us> |
| Cc: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Block-level CRC checks |
| Date: | 2008-09-30 20:48:52 |
| Message-ID: | fd145f7d0809301348j66ca2c5eh3e107d4df369bd1b@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Sep 30, 2008 at 1:41 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Alvaro Herrera wrote:
> > A customer of ours has been having trouble with corrupted data for some
> > time. Of course, we've almost always blamed hardware (and we've seen
> > RAID controllers have their firmware upgraded, among other actions), but
> > the useful thing to know is when corruption has happened, and where.
> >
> > So we've been tasked with adding CRCs to data files.
>
> Maybe a stupid question, but what I/O subsystems corrupt data and fail
> to report it?
Practically all of them. Here is a good paper on various checksums, their
failure rates, and practical applications.
"Parity Lost and Parity Regained"
http://www.usenix.org/event/fast08/tech/full_papers/krioukov/krioukov_html/index.html
-jwb
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Decibel! | 2008-09-30 21:10:58 | Re: Block-level CRC checks |
| Previous Message | Bruce Momjian | 2008-09-30 20:41:59 | Re: Block-level CRC checks |