Comments in-line.
Donovan Baarda <abo@minkirri.apana.org.au> is quoted as saying:
So who's bug is it, and who should fix/workaround it?
part 1) is probably a user problem... the user will just need to
put the required modules into /etc/modules. Arguably the
rc-script priorities of discover, hotplug, and checkfs.sh
(initscripts package) could be tweaked to fix this.
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.
part 2) is possibly a kernel bug, or possibly a mdadm bug, but
the cleanest workaround would be to add the required changes
to /etc/udev/links.conf, either as a default or at least a
README in the udev package.
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.
part 3) is definitely a udev issue. Ideally it would be fixed so
module loading with modprobe would wait until the /dev/* files
are created. I find 3 seconds disturbingly long... I realise
udev would have to scan partitions, but 3 seconds! If it was
made faster this problem would probably go away. Failing a
proper fix, the cleanest workaround is to add a delay after
the /etc/init.d/module-init-tools rc script runs. As it's a udev
specific problem, have the udev package add
an /etc/init.d/udev-wait rc script that runs at priority 21 that
delays to give udev time to create the devices.
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.
Though I am declaratively an "non-programmer" (I only deal with Hardware
and Networks)... maybe this is a good enough reason to change that
though.
--
greg, greg@gregfolkert.net
The technology that is
Stronger, better, faster: Linux
Attachment:
signature.asc
Description: This is a digitally signed message part