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 [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
