thoughts on mdadm and dev node creation

[martin f krafft]

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