thoughts on mdadm and dev node creation
martin f krafft
madduck at debian.org
Fri Aug 18 08:14:31 UTC 2006
also sprach Neil Brown <neilb at suse.de> [2006.08.18.0740 +0100]:
> > I imagine a solution where mdadm simply tells the kernel (via sysfs)
> > to assemble device md1 from e.g. /dev/sd[abc]1, and the kernel then
> > notifies udev to create the device (or, if udev is not used, just
> > makes sure that the existing /dev/md1 then refers to the newly
> > created array?
>
> I have considered that approach. I even have a patch to md lying
> around that allows me to ask for devices to be created without having
> to have the device node first.
> I'm not convinced it is a good idea though.... but I'm not convinced
> it isn't either.
> >
> > This sort of interface would be much better IMHO, because
> >
> > (a) udev is becoming the standard
>
> Yeh, mistakes happen :-) (I'm just be facetious)
I know what you mean and I fully agree. The ideas underlying udev
are IMHO good, but the implementation is a nightmare, and it's
really badly documented. Also, it just seems non-Unix in that it
tries to do way too much. I mean, it was supposed to create device
nodes so that userspace can forget about major/minor device numbers,
right? Now it also renames network interfaces, and generally
processes events and calls hooks for most hardware-related events,
but not all. It's intrusive without addressing all needs, and it
introduces problems while at it.
But it's the converging standard. Better (learn to) live with it. :)
> > (b) udev should thus create /dev nodes, and nothing else
>
> I don't see that.
The theory is simply that mdadm should not know anything about
major/minor device numbers anymore.
> > (c) mdadm via ioctl() requires a /dev node to assemble the array,
> > but udev only gets to find out about the array after it's
> > assembled, at which point the device node already exists. So
> > it's sort of a catch-22 situation.
>
> So simply tell udev to ignore 'md' and let mdadm do all the creation.
This used to break if mdadm assembled during the initramfs, or the
kernel autostarted the devices.
http://bugs.debian.org/382263
With 2.5.3, I noticed that mdadm creates device nodes even for
started arrays, so that sounds like a way around it. I hope to get
some input from the udev maintainer soon.
> I know - I suggested leaving creation of partition nodes to udev.
> I'm not convinced of that either.
What's missing?
> Maybe I should sit squarely on the fence and allow you to choose.
Well, I am trying to make an informed decision, that's for sure :)
> But how would you ask it not do? Maybe use a dev name without any
> slashed.
>
> mdadm -C /dev/md0 -l5 -n4 -x1 /dev/sd[a-e]
>
> Actually creates a device node - minor number 0
>
> mdadm -C md0 -l5 -n4 -x1 /dev/sd[a-e]
>
> Doesn't create any device nodes. They are left to udev. Under the
> hood I would create /dev/..dont-ask as dev node and create the
> device via that (unless some sysfs support was available).
Yes, this sounds like a way to do it. I will ask the udev guys what
they think.
> But then you have to teach your users the different usage... But
> why would you want to?
I just have to make it work. Users can do what they want. It's
a policy-related issue: the user can do whatever s/he wants, but
Debian should do it right by default.
> I cannot help this is a bit of a mountain/mole-hill problem
> created by a desire to auto-configure everything for people.
Yes, but that's the primary benefit of Debian: auto-configuration
without getting in your way. It's just convenience but leaves you in
power, and it's come to be expected. As a developer, I moan, as
a user I cheer!
> If you just expect people to put the names they want to use in
> mdadm.conf just like they do in fstab, then I suspect half the
> problems would go away...
I will require this. At which point it seems like udev won't be
needed, it seems. But I want to make sure to do it right regardless.
Cheers, and thanks for 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
"m.c.s.e": minesweeper consultant & solitaire expert
-------------- 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/20060818/5f6010ea/attachment.pgp
More information about the pkg-mdadm-devel
mailing list