From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Janning Vygen <vygen(at)gmx(dot)de>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: hardware checks (was Re: invalid memory alloc request size) |
Date: | 2006-01-24 05:09:53 |
Message-ID: | 87lkx6us7y.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Janning Vygen <vygen(at)gmx(dot)de> writes:
> > one more question: You mentioned standard disk and memory checks. Can you
> > point to some link where i can find more about it or which software do you
> > mean? I guess i have to start looking at it.
>
> The stuff I've heard recommended is memtest86 for memory checks and
> badblocks for disk checks. But perhaps someone on the list has better
> ideas.
I second memtest86, though even the author says memory errors can be tricksy
things. Sometimes a large compile finds memory errors that even memtest86
doesn't find (the symptom is gcc crashing).
However I fear using badblocks alone is pretty useless these days. Modern IDE
drives detect bad blocks and remap them to other locations. If you just use
badblocks you'll see mysterious errors that disappear or might not see any
errors at all. You need to use tools like smartctl to query the drive's SMART
firmware about errors. It's not easy to interpret but if you watch the numbers
for a while you can tell if a drive is going bad and continually remapping bad
blocks. badblocks is useful still as a way of ensuring that every block is
read and written to, but then you have to look at the SMART data to see what
happened.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Agnes Bocchino | 2006-01-24 08:31:26 | Re: Initdb panic: invalid record offset at 0/0 creating |
Previous Message | surabhi.ahuja | 2006-01-24 05:03:53 | Re: FATAL: terminating connection due to administrator command |