/dev/md0 or /dev/md/0

[martin f krafft]

also sprach tom hall <thattommyhall at gmail.com> [2006.10.29.2028 +0100]:
> I am running testing and wondered which of /dev/md0 or /dev/md/0 is correct.
> /dev/md/0 is a devfs thing right, we are using udev now ?
> mkconf lists the array as /dev/md/0, should i go with that? webmin
> "sees" /dev/md0
> Either work when i get info from them with mdadm, and neither seems to
> be a symlink to the other.
> What is the canonical name?

Please see item 3 of [0]

0. http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/FAQ?op=file&rev=0&sc=0

I prefer /dev/mdX for etch, and I ensured, together with upstream,
that /dev/mdX is always present on etch systems. This means that if
you choose to use /dev/md/X, a symlink to /dev/mdX will be present;
if you work via /dev/mdX directly, *no* symlink to /dev/md/X will be
made.

You are right that /dev/md/X is a relic from devfs times. While
I agree that /dev/md/ would be a more logical approach, it's quite
a break from tradition -- we have /dev/hd[abcd] and not
/dev/hd/[abcd].

Thus, I postponed any further development in this area until after
etch, when I plan to work together with upstream to resolve the
naming issue, ideally by making md play better with udev. Then,
I imagine, mdadm can work as before, but preferably lets udev handle
the actual creation of nodes.

And you are right, mdadm does not care what the device is named --
it only cares about the major/minor pair. The only times when mdadm
worries about those is when you call --examine, or when you ask it
to automatically create nonexistent device nodes. See the FAQ and
the DEVICE NAMES section of the manpage.

-- 
 .''`.   martin f. krafft <madduck at debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"here i was all convinced that if i sleep all day, bug counts go
 down, and if I work all day, they go up, so much for that theory."
                                                   -- lars wirzenius
-------------- 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/20061029/b89f9aba/attachment.pgp