Adaptec ICH5R-S Serial ATA RAID

[Jeremy Chadwick]

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
> 
>