Messages in this thread | | | Date | Fri, 11 Apr 2003 11:31:28 -0700 | From | "Kevin P. Fleming" <> | Subject | Re: [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/
| |