lkml.org 
[lkml]   [2004]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] [DRAFT] [udev PATCH] First attempt at vendor RAID support in 2.6
    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/
    \
     
     \ /
      Last update: 2005-03-22 14:02    [W:0.032 / U:0.112 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site