Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 05 May 2004 22:17:15 +0200
From:      =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@DeepCore.dk>
To:        David Schultz <das@freebsd.org>
Cc:        current@freebsd.org
Subject:   Re: Updated SATA support patches for Intel ICH & Promise cards
Message-ID:  <40994BCB.6000203@DeepCore.dk>
In-Reply-To: <20040505200911.GA2752@VARK.homeunix.com>
References:  <200405041825.i44IPgVa021573@ambrisko.com> <4097F9EA.1080904@DeepCore.dk> <20040505124349.GA612@VARK.homeunix.com> <40990479.6070809@DeepCore.dk> <20040505194949.GA2443@VARK.homeunix.com> <40994763.4090203@DeepCore.dk> <20040505200911.GA2752@VARK.homeunix.com>

next in thread | previous in thread | raw e-mail | index | archive | help
David Schultz wrote:
> On Wed, May 05, 2004, Sren Schmidt wrote:
> 
>>David Schultz wrote:
>>
>>>I have two SATA drives that are mirrored via ccd(4).  The
>>>mirroring apparently introduced some sort of race that led to
>>>problems, which started when ATAng was committed.  The specific
>>>symptoms changed as the ata driver evolved, and varied from kernel
>>>panics in the best case and data corruption in the worst case.
>>>But the details of the problem aren't as important as the fact
>>>that some aspect of Doug's patch fixes them!
>>
>>Have you considered using atacontrol to create an ATA RAID instead ?
>>Does that work ? on an unpatched kernel ?
> 
> 
> This is an Intel 875P motherboard, and I think the controller only
> supports striping, not mirroring.  If this is not the case, I'd
> happily try it, although it would take a while for me to find the
> time to back up and migrate my data if there are any
> incompatibilities.

RAID done by atacontrol and one ATA controllers are just software RAID's 
just like CCD, the only difference is that some controllers has BIOS 
suport for it that allows you to boot from them etc...

> Nevertheless, this completely skirts the issue that there are
> races in the ata driver that are exacerbated by using ccd(4).
> ATA RAID would only be a workaround.

I'm just collecting data about the problem (which I btw cant reproduce 
on an Intel board here). Understanding what happens and why is crucial 
to getting things fixed the right way, and not just applying some random 
hack that seems to fix the problem.

-- 
-Søren



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40994BCB.6000203>