feedback sought on mdadm sarge->etch upgrade strategy

[Marco d'Itri]

On Aug 14, martin f krafft <madduck at debian.org> wrote:

> 1. will udev be default in etch? It does not seem so right now.
It has been installed by d-i since a long time, since it's used by
initramfs-tools.

> 2. in the udev README.Debian, you write that md has design errors.
>    What exactly do you mean?
Exactly this:

>    The problem is that for udev to find out about the individual
>    devices, the arrays have to be started. If mdadm has to start
>    them, it needs devices to send ioctl()s. It even needs devices to
>    find out whether a device is started.

>    be best to eliminate complexity. Of course, it does not work
>    because udev is needed to create the device nodes if they are
>    started during initrd or kernel load.
And /dev/by-disk/ too.

>    There is a mode of mdadm in which it will simply create the
>    device node if it's not there, and it's on by default in sarge
And this is bad, because user space should not need to know about
major/minor numbers.

>    If, however, mdadm creates a /dev/md/X node, udev will then
>    create /dev/mdX, and this confuses the hell out of mdadm later,
>    so I really would like to stop udev from creating the node
>    /dev/mdX when mdadm creates /dev/md/X. How?
I can think about a few hacks which could accomplish this, but I suggest
you first send again this message to the
linux-hotplug-devel at lists.sourceforge.net upstream mailing list, where
there are more people looking at the big picture.

And anyway, why can't you make mdadm less confused by multiple device
nodes? What is the problem, exactly?

-- 
ciao,
Marco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-mdadm-devel/attachments/20060814/c89da281/attachment-0001.pgp