Bug#273182: udev doesn't create /dev/md* in time for mdadm-raid to start them. All sw-raid filesys fail to mount.
responding to the web archive here... apologies for bad quoting.
> This is entirely unsatisfactory, adding lines
> to /etc/modules? /etc/modules is deprecated and should not be around if
> you are using modprobe, hotplug, discover..et-al. This is just bad
> advice or workaround.
Deprecated or not, /etc/modules is still the earliest possible place to
load modules, short of compiling them into the kernel. As I said, the
order of discover and hotplug could be re-arranged so they are early
enough to load modules for mdadm-raid, but then many other things may
need to be re-arranged.
Also, /etc/modules is also the only place to explicitly load modules not
detected or miss-detected by the autodetect tools... for this reason I
suspect it will never go away.
> Wow this is great, tell us to use a file which explicitly has this as
> its header:
>
> # This file does not exist. Please do not ask the debian maintainer about it.
> # You may use it to do strange and wonderful things, at your risk.
>
> So you propose to have this fugly hack in a Production system? (later
> when Sarge is released. I'd like to think not.
Yeah, I read that. I suspect it is the udev maintainer in denial that
the features that it provides are really needed. The reality is, udev
must create the md0 devices. The md module doesn't notify it that they
need to be created. This is the best way I know udev can be told to
create device nodes.
> Ouch, 3 seconds on relatively small systems might just work. How about
> systems with multiple racks of storage or storage with multiple LUNs, or
> exceptionally large LUNs with 35+ Partitions? Are you sure 56 ticks is
> enough... I don't think so.
>
> Even then a sleep... is a terrible hack. Though it is used gratuitously
> in many places, mostly in bad places to "trick" the said programmer into
> thinking it is "F1X3d". I am not slamming anyone here, just the
> practice.
Yeah, its a hack. The real solution should probably be;
"modeprobe <blah>" does not complete until device <blah> is loaded and
ready to be used. In this case, modeprobe should interact some how with
udev and not terminate until udev has created the device nodes.
However, I'm not sure modprobe can do that easily... I dunno how the
kernel/modprobe/udev interactions work, but I have a feeling modprobe
cannot easily ask udev when it is finished.
On a system with bucket-loads of partitions this means modprobe could
take ages. But even if modprobe didn't wait for udev, anything that
wanted to mount those partitions would still have to wait for udev.
Unless udev can be made faster, it will probably prove to be unusable on
such systems.
--
Donovan Baarda <abo@minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/
Reply to: