[lkml]   [2003]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[RFCI] How best to partition MD/raid devices in 2.6

    RFCI == Request For Clever Ideas.

    Hi all..

    I want be able to partition "md" raid arrays.
    e.g. I want to be able to use RAID1 to mirror sda and sdb as whole
    drives, and then partitions that into root, swap, other (or whatever
    suits the particular situation).

    I am already doing this on 2.4 based kernels using a local patch
    which is unlikely ever to get into the kernel.

    This patch declares a new major number and uses it to address upto 15
    partitions on each of the first 16 md arrays.
    Not only does this limit you do only partitioning 16 md arrays, but
    it means that there are two separate devices (major+minor) that
    access the same device. In 2.4 this is just untidy. In 2.6 it would
    also subvert the exclusive access provided by bd_claim, and that
    isn't a good thing.

    So I'm looking for a nice clean way to provide partitioning of md
    devices in 2.6.
    In 2.6 we have 20 bits for minor number and I am quite happy to
    require the use of them - i.e. there is no need for the approach to
    work equally well in 2.4.

    Backwards compatibility is fairly important, and that means that the
    first 256 minor numbers for block major number '9' have to still be
    whole md arrays.

    Some options that occur to me are:

    1/ compile time option that redefines major 9 to use 6 bits for
    partition information. This throws backwards compatibility out the
    window and is a nice clean way forward. I think this would be a
    support nightmare and I wouldn't impose it on anyone.

    2/ new major number which uses 6 bits for partitioning and provide
    some sort of interlock so that you cannot access the same raid
    array from both the old and the new major at the same time.
    I'm not sure how easy the interlock would be, but it is probably
    do-able. The problem is that I would like a well-defined major
    number and Linus doesn't seem keen on any more of those (though I
    realise that isn't unanimous).
    There was once talk of a 'disk' major number and all the things
    that looked like discs would come under that somehow, but that
    doesn't seem to have eventuated. Maybe it should, but there would
    still be the interlock problem

    3/ define minor numbers of block-major-9 that are larger than 255 to
    have 6 bits of partitioning information. i.e.
    9,0 -> md0
    9,1 -> md1
    9,255 -> md255
    9,256 -> md256
    9,257 -> md256p1
    9,257 -> md256p2
    9,320 -> md257
    9,321 -> md257p1
    This has least impact on other system and is in some ways simplest,
    but it has the problem of lack of uniformity. You wouldn't be able
    to partition md0, but that isn't a big problem as long as you can
    partition some md arrays.

    4/ just use 'dm', or write a new 'md' module that can present a
    partition of a device. Then leave the setup to user-space.
    This is least impact on the kernel, but most impact on
    user-space. It would not be too hard to create a userspace tool
    that made most of this fairly transparent.
    Particularly if it was a new 'md' personality, userspace could
    then effectively decide how the minor numbers of block-major-9
    were used with respect to partitioning.

    There are probably other options and I would be happy to hear them.
    My personal preference is wavering between 4 (using md) and 2.
    Possibly I should learn more about how 'dm' could handle it for me..

    Opinions welcome,
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:58    [W:0.025 / U:0.568 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site