From owner-freebsd-current@FreeBSD.ORG Thu Sep 23 19:41:57 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 00F7D16A4CE for ; Thu, 23 Sep 2004 19:41:57 +0000 (GMT) Received: from mail.parodius.com (mail.parodius.com [64.62.145.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDB0843D41 for ; Thu, 23 Sep 2004 19:41:56 +0000 (GMT) (envelope-from jdc@pentarou.parodius.com) Received: from pentarou.parodius.com (jdc@localhost [127.0.0.1]) by mail.parodius.com (8.13.1/8.13.1) with ESMTP id i8NJfuKq081281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Sep 2004 12:41:56 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.13.1/8.13.1/Submit) id i8NJfuG7081280 for freebsd-current@freebsd.org; Thu, 23 Sep 2004 12:41:56 -0700 (PDT) (envelope-from jdc) Date: Thu, 23 Sep 2004 12:41:56 -0700 From: Jeremy Chadwick To: freebsd-current@freebsd.org Message-ID: <20040923194156.GA81108@parodius.com> Mail-Followup-To: freebsd-current@freebsd.org 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> <41527A9D.2080700@DeepCore.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <41527A9D.2080700@DeepCore.dk> User-Agent: Mutt/1.5.6i 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 19:41:57 -0000 Soren, The metadata for ICH5R shouldn't be that hard -- it was added to Linux fairly recently, by Intel (!). The source-code is open and available. I believe I mentioned this in PR 60344. Applicable URLs: http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/60344 http://www.ussg.iu.edu/hypermail/linux/kernel/0311.3/0222.html ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/ I hope this helps somewhat. I presently _don't_ have a system I can test this on (need to get another one up and going for that), but should within a month or so. Just started a new job, waiting for the money to start coming in... And yes, I'll re-iterate what you said: this isn't suitable stuff for RELENG_5, but is worth testing under -CURRENT. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Thu, Sep 23, 2004 at 09:26:21AM +0200, Søren Schmidt wrote: > 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 > Intel RAID metadata (not even the one thats made by Intel) they all use > 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 different > >story. > > > >>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 > things for 5.3. There are a few issues that needs to be looked at and > that has higher priority (for me at least). > > Now, one of the reason I havn't put more metadata formats in there is > that its no longer enough to use the chip PCI ID to find out what > 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 > 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 > released docs/info on how those formats are done, so each new format > 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. > The way it plugs into the disks strategy routines is a hack at best. It > also needs to be able to take advantage of those chips that can do some > part of the RAID stuff (Promise, Marvell, AHCI). > > So, there is plenty to do as usual, and I have to balance priorities > amongst it all. > > Back to the matter at hand, if this patch is going into ata-raid.c it > 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 > the new ata-raid.c unless someone does the integration when time comes. > We also need to have some kind of resolution to the problem with more > than one format pr device id. > > And no, this is *not* RELENG_5 material, not even close. > > -- > > -Søren > >