From owner-freebsd-current@FreeBSD.ORG Thu Sep 23 07:26:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 434CB16A4CE for ; Thu, 23 Sep 2004 07:26:32 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FB7D43D2F for ; Thu, 23 Sep 2004 07:26:31 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i8N7QTGl000512; Thu, 23 Sep 2004 09:26:30 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <41527A9D.2080700@DeepCore.dk> Date: Thu, 23 Sep 2004 09:26:21 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeremy Chadwick References: <200409212256.i8LMu1b7032629@sage.ts.co.nz> <41517193.60604@nulis.lt> <1521.66.11.183.178.1095880306.squirrel@66.11.183.178> <20040922220330.GA48125@parodius.com> In-Reply-To: <20040922220330.GA48125@parodius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: freebsd-current@freebsd.org Subject: Re: Adaptec ICH5R-S Serial ATA RAID X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2004 07:26:32 -0000 Jeremy Chadwick wrote: > As I mentioned, Soren may not have an ICH5R to test with. If he > doesn't, I can send him a motherboard (no CPU or RAM though) which can > help with this department. I do have ICH5(R) and 6300ESB boards around, but none of them uses the=20 Intel RAID metadata (not even the one thats made by Intel) they all use=20 Adaptec HostRAID which I have partial support for (unreleased yet). > I think it's "too soon" to get this into RELENG_5, to be honest, unless= > things happen over the next 7-8 days. -CURRENT is an entirely differen= t > story. >=20 >>From what I understand, there's been a lot of work recently on getting > metadata support for different onboard RAID controllers. Soren could > comment on this... Yes there has, but lately my efforts has concentrated on stabilizing=20 things for 5.3. There are a few issues that needs to be looked at and=20 that has higher priority (for me at least). Now, one of the reason I havn't put more metadata formats in there is=20 that its no longer enough to use the chip PCI ID to find out what=20 metadata to look for, I know of at least 3 different formats used on SiI = chips. This needs some thought as we might not want to scan all disks for a=20 dozen different formats. And if more than one format is found on a disk, which one do we use ? Another issue is that no vendors except Promise and Highpoint has=20 released docs/info on how those formats are done, so each new format=20 need a fair amount of reverseengineering and testing to be made at least = semireliable. On top of that, ata-raid.c needs a serious rewrite for other reasons.=20 The way it plugs into the disks strategy routines is a hack at best. It=20 also needs to be able to take advantage of those chips that can do some=20 part of the RAID stuff (Promise, Marvell, AHCI). So, there is plenty to do as usual, and I have to balance priorities=20 amongst it all. Back to the matter at hand, if this patch is going into ata-raid.c it=20 will need a maintainer. Since I dont have HW with this format around it = wont get any testing/support from this end and will not be provided in=20 the new ata-raid.c unless someone does the integration when time comes.=20 We also need to have some kind of resolution to the problem with more=20 than one format pr device id. And no, this is *not* RELENG_5 material, not even close. --=20 -S=F8ren