Date: Thu, 23 Sep 2004 09:26:21 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@DeepCore.dk> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-current@freebsd.org Subject: Re: Adaptec ICH5R-S Serial ATA RAID Message-ID: <41527A9D.2080700@DeepCore.dk> In-Reply-To: <20040922220330.GA48125@parodius.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41527A9D.2080700>