feedback sought on mdadm sarge->etch upgrade strategy

[martin f krafft]

also sprach Marco d'Itri <md at Linux.IT> [2006.08.14.2245 +0100]:
> > 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.

Ok, I suppose this is good news.

> > 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.

So instead, it should just tell the kernel to create an array by
some other interface? So the md driver should provide a better sysfs
interface?

> >    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.

Agreed.

> >    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.

Done.

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

I'll answer that on the list.

Thanks for the hint and your time!

-- 
 .''`.     martin f. krafft <madduck at debian.org>
: :'  :    proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"oh what a tangled web we weave,
 when first we practice to deceive."
                                                        -- shakespeare
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (GPG/PGP)
Url : http://lists.alioth.debian.org/pipermail/pkg-mdadm-devel/attachments/20060814/e7c183c9/attachment.pgp