[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#273182: Certain things don't add up....

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

Though I am declaratively an "non-programmer" (I only deal with Hardware
and Networks)... maybe this is a good enough reason to change that
greg, greg@gregfolkert.net

The technology that is
Stronger, better, faster:  Linux

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: