Hi,

[this is not only a reply to Thomas' mail, but also an update about the
current state of my vendor RAID support]

Greg: Would you accept this patch into your udev package?

Thomas Horsten wrote:
> Hi Carl-Daniel,
> 
> On Thu, 15 Apr 2004, Carl-Daniel Hailfinger wrote:
> 
> 
>>What I need:
>>- People looking at the *_sb_helper functions to tell me if there is more
>>magic I can check for

Partly solved, check below.


>>- Criticism of coding style/ missing abstraction

I got a mail from Barlomiej Zolnierkiewicz where he suggested to split the
vendor dependent code out of raiddetect.c. This will happen in one of the
next revisions.


>>- People checking the numerous FIXMEs

I now have the following FIXMEs (aka "I have no idea about it"):
- 5 FIXMEs in the Medley RAID code. Thomas, could you comment once you're
back?
- 3 FIXMEs in the Highpoint RAID code. Wilfried, could you please take a
look at them?
- 2 FIXMEs in the Promise RAID code. I will on those myself.
- some generic FIXMEs:
  - Is the sector size of a harddisk always 512 bytes?
  - Is /sys/block/*/size always in 512-byte units?
  - Are there controllers out there which occupy more than one PCI device?
  - How can I find out if a block device under /sys/block is a disk?


>>- More data about Medley/Highpoint vendor superblocks (can I check for
>>bogus values?)

Wilfried, is there any consistency check I can add for Highpoint?


>>- Help with sorting out who owns which copyrights

This is still a _big issue_.


> I'm on holiday in New York right now so I don't have time to give you a
> complete breakdown. But I can give you a couple of comments on Medley RAID
> and get back to you when I return next week.

Thanks!


> First: It should not be called "SIL", "SII", or "Silicon Image" RAID in
> the parts of the code exposed to the user. This is because other vendors
> than Silicon Image use the Medley RAID specification (such as the CMD680R
> SATA controller and others). When refering specifically to Silicon Image,
> SII is the correct abbreviation, not "SIL".

Changed.


> You are asking for more magic to detect Medley RAID. The probe function
> for Medley in my patch (medley_probe_drive()) first calls
> medley_get_metadata() which uses the checksum to determine if it is a
> Medley superblock. In my version, it also checks the PCI vendor ID/product
> ID against that stored in the Medley superblock. This is consistent with
> how the Medley BIOS verifies a valid Medley superblock and you should rely
> on this for automatic detection. But since users might want to move the
> RAID set to a different controller, e.g. if their on-board controller
> breaks down, there should be an option to force detection to bypass the
> PCI ID verification.

medley_sb_helper now has a parameter ignore_vendorid (default off).


> After you have a correct checksum there are several other things you can
> check for, which I do in my medley_probe_drive() after obtaining the
> superblock:
> 
> - Check raid_type, it should be 0 for striped sets (RAID0) - I will get
> you the values for RAID1 and RAID1+0 when I return from NY.

Will be added as soon as I get the data.


> - Check major_ver, it should be 1 or 2 (other major versions may have a
> different superblock and can not be supported).

Will be added once I have more info about the expected checksum value for
different superblock versions (see FIXME there).


> - Check that the chunk_size looks reasonable, that there is more than

The chunk_size>0 check is now in. Can I do better chunk_size checking?


> 1 drive in the set (drives_per_striped_set), and that the drive_number
> is within the range 0-(drives_per_striped_set-1).

Done.


> If you do all these checks and still come out with a valid candidate, it's
> probably safe to assume that the drive belongs to a set if all the disks
> are present.

Attached is my current version of raiddetect.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/