Re: pg_clog woes with 7.3.2 - Episode 2
От | Tom Lane |
---|---|
Тема | Re: pg_clog woes with 7.3.2 - Episode 2 |
Дата | |
Msg-id | 3008.1050550771@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_clog woes with 7.3.2 - Episode 2 (Kevin Brown <kevin@sysexperts.com>) |
Список | pgsql-hackers |
Kevin Brown <kevin@sysexperts.com> writes: > If badblocks shows errors but you don't see any SCSI errors in the > system logs, then it's time to start suspecting the disk controller or > perhaps even the PCI bus controller, because it means something really > weird is happening on the backend that is entirely invisible. Cabling > or termination could be an issue, but I'd expect to see parity errors, > timed out commands, etc. if that's the problem. Dave neglected to mention that the two or three bad blocks we'd traced down all showed a consistent pattern of errors: there was a 64-byte region of wrong data, aligned on a 64-byte offset from the start of the disk block, and the contents were copies of correct data from positions exactly 64 bytes before or after the bad area. Considering that, I would bet a good deal that the problem is some kind of transfer timing error in some chunk of hardware that copies the data 64 bytes at a time. I withdraw my previous thought that it might be cabling --- there are no 64-byte-wide SCSI cables. It could easy be internal to the SCSI adaptor though. If his motherboard is high-end enough that the DMA path from adaptor to memory is 64 bytes wide, then DMA timing errors would be a possibility too. regards, tom lane
В списке pgsql-hackers по дате отправления: