xfs
[Top] [All Lists]

Re: XFS corruption on SoftRAID5

To: Seth Mos <knuffie@xxxxxxxxx>
Subject: Re: XFS corruption on SoftRAID5
From: Simon Matter <Simon.Matter@xxxxxxxxxxxxxxxx>
Date: Fri, 29 Jun 2001 22:53:29 +0200
>received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 9F04157306; Fri, 29 Jun 2001 23:03:58 +0200 (CEST)
Cc: Andrew Klaassen <ak@xxxxxxx>, linux-xfs <linux-xfs@xxxxxxxxxxx>
References: <Pine.BSI.4.10.10106292212520.26374-100000@xxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
Seth Mos schrieb:

> On Fri, 29 Jun 2001, Andrew Klaassen wrote:
>
> > On Fri, Jun 29, 2001 at 12:28:06PM -0400,
> > Martin K. Petersen wrote:
> >
> > > FWIW, almost all the XFS corruption bugs (with RAID or
> > > otherwise) I've seen so far have been incorrect IDE hdparm
> > > tuning or bad cabling.
> >
> > My question is really OT for this list, but how might one go
> > about checking for bad cabling?  Is there any software that can
> > find it consistently?
>
> If the cable is not correct some cards will report it.
> The promise controllers can report if a IDE cable is 80 pins or not.

That's correct. But I think they just recognize whether it's 40 or 80
wires cable.
Cables have always 40 pins, but 80 wires.

>
>
> And the kernel sometimes also gives back errors. I have seen it once
> already. The ATA66 and ATA100 standard have CRC checking for data sent

CRC is what they should do, but I'm not shure they really do it always.

>
> over the cable. However forcing another a transfer mode is dangerous
> and does net let a IDE interface set the correct mode on its own.

>
> I don't know if scsi has some form of CRC control.\

It has, it's not CRC but parity checking. Most controllers let you
en/disable it.

>
>
> Bye

<Prev in Thread] Current Thread [Next in Thread>