SATA controllers and kernel port assignment in Linux - Hardware

This is a discussion on SATA controllers and kernel port assignment in Linux - Hardware ; Okay, I've done quite a bit of searching and haven't been able to come up with a great answer, so I decided to post here. This is the quick and dirty explanation. I have a total of 6 SATA ports. ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: SATA controllers and kernel port assignment in Linux

  1. SATA controllers and kernel port assignment in Linux

    Okay, I've done quite a bit of searching and haven't been able to come
    up with a great answer, so I decided to post here.

    This is the quick and dirty explanation. I have a total of 6 SATA
    ports. 2 on the motherboard and 4 more on a PCI add on card. Is there
    anyway to gap/assign these ports? Right now, the kernel is simply
    assigning the device numbers in the order in which things are found. I
    would like to be able to manually assign these in order to leave gaps.
    So that the port is always assigned to the same /dev/ designation
    whether a drive is present or not:

    Port 1 MB - /dev/sda
    Port 2 MB - /dev/sdb
    Port 1 Card - /dev/sdc
    Port 2 Card - /dev/sdd
    Port 3 Card - /dev/sde
    Port 4 Card - /dev/sdf

    Right now I have one drive on the motherboard (/dev/sda) and two drives
    on the Card (/dev/sdb and /dev/sdc). The two drives on the card are
    mirrored in a software raid-1 configuration. If in the future I add
    another drive to the second port on the motherboard, it will be
    assigned as /dev/sdb and then my raid drives will jump to /dev/sdc and
    /dev/sdd. I can rebuild the raid at that point, but that always makes
    me nervous

    Obviously, this is not a problem without work arounds, but I would like
    to know if it is possible to hard assign the ports to the /dev/
    configuration even though there may not be a drive there at the time.

    I hope this made sense....


  2. Re: SATA controllers and kernel port assignment in Linux

    darrins@gmail.com wrote:
    >
    > Right now I have one drive on the motherboard (/dev/sda) and two drives
    > on the Card (/dev/sdb and /dev/sdc). The two drives on the card are
    > mirrored in a software raid-1 configuration. If in the future I add
    > another drive to the second port on the motherboard, it will be
    > assigned as /dev/sdb and then my raid drives will jump to /dev/sdc and
    > /dev/sdd. I can rebuild the raid at that point, but that always makes
    > me nervous


    There shouldn't be any need to re-build the array. Assuming you're
    talking about a modern soft-raid with partition type 0xfd (RAID
    autodetect), the kernel doesn't care about the /dev/sd* names. What
    matters is the GUID that's written into the RAID superblocks of those
    devices. The kernel will create the RAID from the matching pair of
    GUIDs regardless of their /dev names.

    IOW, I think you're worried about nothing.

    (FWIW, I've been through this re-naming of disk devices multiple times
    with real SCSI devices. The only problem was with non-RAID partitions
    making it necessary to update /etc/fstab. But mounting by FS label
    instead of device node would avoid that problem, too.)

  3. Re: SATA controllers and kernel port assignment in Linux


    > There shouldn't be any need to re-build the array. Assuming you're
    > talking about a modern soft-raid with partition type 0xfd (RAID
    > autodetect), the kernel doesn't care about the /dev/sd* names. What
    > matters is the GUID that's written into the RAID superblocks of those
    > devices. The kernel will create the RAID from the matching pair of
    > GUIDs regardless of their /dev names.


    hmmmm. I am obviously not doing something right then. This is
    probably a topic for another group, but I recently had some real
    struggles with this.

    >
    > IOW, I think you're worried about nothing.


    You are probably right. I appreciate the answer and the confirmation
    that what I am trying to do is not only not possible, but not necessary
    as well. I can stop wasting my time now.

    Thanks.


  4. Re: SATA controllers and kernel port assignment in Linux

    I believe that static device naming, based on serial number or several
    other identifiers, can be achieved via "udev". In addition to the
    generic system rules that you're facing, you can add your own specific
    rules to make arbitrary-named device nodes. I've never tried this, I
    can't provide cookbook-style examples, but I believe this is
    achievable. It is commonly referred to in consequence with USB
    hot-swappable devices, but I see no reason why this wouldn't work with
    SCSI devices.

    I can see one problem here: the static naming works at the level of
    device nodes (filenames in a filesystem), that are somehow
    automagically mapped onto minor numbers that have emerged in the system
    on boot or at runtime. Unfortunately, udev cannot affect the device
    minor numbers per se. The kernel will still assign SCSI minor numbers
    as ordinal numbers, based on the order in which it discovers the SCSI
    disks.

    Thus, if you get the rules right, you'll see your disks with constant
    /dev/something names, which you can use in /etc/raidtab or mdadm.

    But, you won't be able to affect the underlying minor numbers. These
    will change spontaneously if you reboot with a drive missing or
    something like that. The kernel-space "md" driver doesn't know about
    user-space device nodes, it can only work with the minor numbers. If
    indeed the "md" driver works irrespective of minor numbers, based on
    generated GUID identifiers, as someone here has already suggested,
    you're on the safe side. If however this didn't really work, that would
    be really bad luck, as no udev-based black magic would save you :-(

    Frank Rysanek


  5. Re: SATA controllers and kernel port assignment in Linux

    darrins@gmail.com wrote:
    >
    > I appreciate the answer and the confirmation
    > that what I am trying to do is not only not possible


    I didn't say that it wasn't possible. (I was very careful to avoid that
    statement!) I said it shouldn't be necessary.

  6. Re: SATA controllers and kernel port assignment in Linux



    On Mon, 4 Dec 2006, John-Paul Stewart wrote:

    > darrins@gmail.com wrote:
    >>
    >> Right now I have one drive on the motherboard (/dev/sda) and two drives
    >> on the Card (/dev/sdb and /dev/sdc). The two drives on the card are
    >> mirrored in a software raid-1 configuration. If in the future I add
    >> another drive to the second port on the motherboard, it will be
    >> assigned as /dev/sdb and then my raid drives will jump to /dev/sdc and
    >> /dev/sdd. I can rebuild the raid at that point, but that always makes
    >> me nervous

    >
    > There shouldn't be any need to re-build the array. Assuming you're talking
    > about a modern soft-raid with partition type 0xfd (RAID autodetect), the
    > kernel doesn't care about the /dev/sd* names. What matters is the GUID
    > that's written into the RAID superblocks of those devices. The kernel will
    > create the RAID from the matching pair of GUIDs regardless of their /dev
    > names.


    Is there an easy, safe way to migrate from the old raidtools style RAID to
    the new auto-detect mdadm type arrays?

    I suppose that I could manually fail one device in my old (RAID1) array
    and then define a partiton on this drive as a new mdadm-style array (with
    a missing drive), copy the data over, then re-partition and add the other
    drive and re-build, but is there an easier way?

  7. Re: SATA controllers and kernel port assignment in Linux

    Whoever writes:
    >Is there an easy, safe way to migrate from the old raidtools style RAID to
    >the new auto-detect mdadm type arrays?


    I don't remember what we did, but we created a RAID 1 with raidtools2,
    and later just managed it with mdadm, no reformatting required. AFAIK
    there is an older RAID format, but my impression from reading the
    documentation was that that format could also be managed by mdadm.

    - anton
    --
    M. Anton Ertl Some things have to be seen to be believed
    anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
    http://www.complang.tuwien.ac.at/anton/home.html

+ Reply to Thread