[lkml]   [2004]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: ATARAID userspace configuration tool
    Am Di, den 10.02.2004 schrieb Kevin P. Fleming um 19:26:

    > > I have a really bad idea :)
    > >
    > > Try to combine it with udev. udev calls the ide script, the ide script
    > > then calls the ataraid detector. If the device is non-ataraid, go on as
    > > usual. If it is, build the device-mapper device and symlink (if it
    > > doesn't already exist) and tell udev to not create anything.
    > This is not a bad idea, it's the future.

    I was just joking. I said that because it's not complete.

    > The hotplug mechanism is
    > exactly what should be used here. When a block-device hotplug ADD event
    > occurs, you look at that device to see if it's something you care about.
    > If not, just exit and leave it alone.

    udev maintains a database of already created devices. And sysfs is some
    sort of database of really existing devices. The "telling udev to not
    create the device and instead create it ourself" is bad. We should be
    able to tell udev that it should register and create another device
    instead. Perhaps udev should know about compound devices.

    I'm not sure but if udev knows about compound devices things get a bit
    more complicated. A raid 1 setup would continue to work if one of the
    devices is unplugged, a raid 0 setup fails to work if one device is
    missing. Probably the device should be deleted only when both hard disks
    are removed. Also it should be created if only one hard disk gets
    plugged in. But on bootup if some script tells udev that one hard disk
    is there and some seconds later that the second is also there the tool
    shouldn't assume the raid has failed after seeing the first event.

    Should we Cc an udev developer for an opinion?

    > Now in the ATARAID case, where you need to see multiple devices before
    > you can do anything with them, this means you'd need to keep some
    > "state" somewhere about the devices you've seen so far, and the partial
    > ATARAID devices they represent. When you get the hotplug event for the
    > last piece of a particular ATARAID device, you use DM/MD to set up the
    > device and make it available.

    As I said I think it is more complicated.

    > The wonderful part of this is, when you do that last step, _another_
    > block-device hotplug ADD event occurs for the new device you just
    > created, and if the hotplug scripts are set up to run dmpartx or its
    > equivalent for new block-devices, you are done.

    Right. dmpartx should run on dm-[0-9]* and md[0-9]* events (but not
    recursively of course ;)).

    > The partition tables
    > _inside_ the ATARAID device will be read, more DM calls will be made to
    > make those sub-devices available to userspace and everyone is thrilled
    > about the elegance of the solution :-)

    Yes, sounds cool.

    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 14:00    [W:0.023 / U:35.248 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site