lkml.org 
[lkml]   [2003]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ANNOUNCE] udev 0.1 release
    Antonio Vargas wrote:

    > On Fri, Apr 11, 2003 at 06:46:09PM +0100, John Bradford wrote:
    >
    >>>>- Performance. What happens if you plug in 4000 disks at once?
    >>>
    >>>You crash your power supply :)
    >>
    >>[Puzzle]
    >>
    >>Say the power supply had five 5.25" drive power connecters, how many 1
    >>into 3 power cable splitters would you need to connect all 4000 disks?
    >>

    OK, this is all fun and games, but this is a valid point. All it takes for the
    driver for a Fibre Channel host adapter to load, and enumerate the devices it
    can see. In a matter of seconds many hundreds or thousands of disk devices could
    be registered with the kernel.

    This is definitely an issue that will need to be addressed, and I think Oliver's
    suggestion of using a pipe (i'm going to say it: like devfs did :-) to forward
    the events to /sbin/hotplug in a FIFO fashion makes some sense. I have also been
    considering this issue from another angle; I am working on userspace partition
    discovery, which will be driven by /sbin/hotplug (and udev, probably). I have
    concerns that the following scenario will cause problems, if not extreme problems:

    - kernel driver finds an IDE drive, registers it and the hotplug event happens
    - udev gets called and gives it device node /dev/discs/disc0 (or whatever)
    - /sbin/hotplug calls userspace partition discovery, which opens the device and
    scans for partitions
    - if any partitions are found, they are registered with the kernel using
    device-mapper ioctls
    - because these new "mapped sections" of the drive are _also_ usable block
    devices in their own right, they generate hotplug events
    - because these hotplug events are for new block devices, userspace partition
    discovery will get called _again_ to handle them (it may not find anything (the
    normal case), but this model will support nearly infinite levels of partitioning
    on any block device supported by the kernel)

    What happens if these secondary hotplug events occur while /sbin/hotplug has not
    yet finished processing the first one? Ignoring locking/race issues for the
    moment, I'm concerned about memory consumption as many layers of
    hotplug/udev/kpartx/etc. are running processing these events.

    Of course, another possibility I'll look into this weekend is to actually have
    kpartx run as a daemon and receive messages over D-BUS, instead of being invoked
    directly by /sbin/hotplug. This would mean it could serialize the events itself
    and reduce some of the load (if D-BUS supports message queueing, which I believe
    it does).

    Actually, here's another thought: have the kernel continue to call /sbin/hotplug
    for every event, just as it does now. However, /sbin/hotplug would do _nothing_
    but translate that into D-BUS messages and post them. udev, kpartx, etc. would
    all just be D-BUS clients that would respond to their messages as they are received.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:34    [W:0.033 / U:153.520 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site