This cycle a few things were done in mdadm & dmraid packages to
prepare for transition from dmraid to mdadm for a few formats that
mdadm supports.
At the moment it trusty, mdadm has full support to assemble Intel
Matrix Raid and DDF fakeraid arrays, instead of dmraid. At the moment
however, mdadm codepath is disable via a kernel cmdline options
(nomdmonddf nomdmonisw) and thus if both mdadm and dmraid are present
in the initramfs dmraid will complete assembly. With or without kernel
options, dmraid completes assembly if mdadm is not present. Thus
existing upgrades continue to work as they are.
However to complete the upgrade, i would like remove the feature flag
and enable mdadm based assembly, such that installing mdadm migrates
systems using dmraid for Intel Matrix Raid and DDF fakeraids to mdadm.
But further changes are required, as the device names change when
moving from dmraid to mdadm, e.g.:
dmraid names:
* /dev/mapper/isw_cbhjgfachh_Volume1
* /dev/mapper/isw_cbhjgfachh_Volume1p1
* /dev/mapper/isw_cbhjgfachh_Volume1p2
* /dev/mapper/isw_cbhjgfachh_Volume1p3
become under mdadm:
* /dev/md/Volume1
* /dev/md/Volume1p1
* /dev/md/Volume1p2
* /dev/md/Volume1p3
Thus changes to /etc/fstab, and/or bootloader are required to look for
new places.
The question I have, is whether such migration should be done
automatically or left in the hands of the administrator (e.g. if mdadm
is not installed, dist-upgrade is performed no changes are required
and dmraid is continued to be used. If one installs mdadm, one would
also need to either disable mdadm-fakeraid assembly with kernel
cmdline options or adjust /etc/fstab & grub for the new names).
One solution I had in mind is to generate compat symlinks
(/dev/mapper/isw_cbhjgfachh_*) using udev rules, as that stable name
can be calculated based on the inspected array information. And thus
no changes would be required on the admins side upon upgrading to
mdadm. However symlinking /dev/md/* devices into /dev/mapper/* feels a
bit ugly, given that they are not devmapper managed. And I'm still
trying to construct sensible udev rule to do that.
Alternatively, we can rely on everyone to use filesystem UUIDs and/or
LVM stable names, and then hide the partitions/filesystems on the raw
devices (/dev/sda /dev/sdb etc) using partx -d, and only expose
filesystems/lvm/etc. off the assembled raid array devices.
Should dmraid installation migrate to mdadm, if mdadm is installed?
If yes, then how?
Or should mdadm, upon upgrade, notice that system is currently using
dmraid and configure itself to not disturb that in anyway, unless
explicit action by administrator is taken?
(e.g. write out the feature-flag config snippet)
Also i have a pending patch for hw-detect to offer assembling fakeraid
arrays using mdadm ahead of assembly with dmraid. Such that
installation can be completed without dmraid. But that relies on
removing featureflag from mdadm, and resolution to the upgrade path
for existing fakeraid installations.
--
Regards,
Dimitri.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
