feedback sought on mdadm sarge->etch upgrade strategy
martin f krafft
madduck at debian.org
Mon Aug 14 22:18:10 UTC 2006
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
More information about the pkg-mdadm-devel
mailing list