md[adm] device names

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello.

Mdadm 3.x introduced a subdirectory for all md-related
deice nodes, /dev/md/.  (To be exact, that directory were
introduced earlier, but starting with 3.x it's the default
location).

The question is, the short form: can we get the naming back?
Or, at least, some plan for migration (with a justification
as of _why_ the move)?

I tried new mdadm package on a Debian system.  And what
I ended up is a complete mess.

The system boots with root=UUID=xyz parameter, even if
my /etc/fstab lists /dev/md1p1 as root device.

When it boots (during initramfs), the array gets assembled in
/dev/md/d1, even if mdadm.conf lists /dev/md1.  So the
mount(8) command lists root on /dev/md/d1p1.

When udevd is re-scanning device nodes from real root, it
creates /dev/md1 and not /dev/md/d1.

When update-initramfs script runs, mdadm-related parts
complains that there's no definition found for array
/dev/md/1_0.

I understand that some of that are Debian-specific, probably
broken workarounds for the name change.  But the root cause
is the renaming, it looks like.

So the question is, the long form:

 Why the rename to start with?  The kernel already knows
 its devices by name, and uses _plain_ naming, without any
 subdirectory: like /sys/block/md1, /proc/partitions and
 so on.  I expect to find the names which are used by
 kernel in /dev as-is.  Other tools expexts the same,
 and some even complains and errors out if they can't
 (notable lilo).  If we want subdirectory, how about
 renaming them in the kernel?  But there aren't that
 many md devices to justify the subdirectory, IMHO.

 I understand about symbolic names (home, volume0,
 backup etc) - those may go to /dev/md/home and so
 on.  But can we please, pretty please, make these
 a sumlinks to the real device nodes as kernel sees
 them?  Like all the /dev/disk/by-xx/* symlinks are?
 Since these are really just _aliases_ for the kernel
 device names...

 I can hear the famous "policy does not belong to the
 kernel" thing here, the same way as with udev.  But
 it didn't work out for several years of udev already,
 and what we have now with mdadm is a _lack_ of policy
 instead of _some_ policy, which is nothing more than
 a big mess.

This is getting out of control.

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux