On 20.02.2014 16:49, Dimitri John Ledkov wrote: > 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.
Personally, when thinking about it, it feels wrong to create links inside and with naming used by device-mapper targets from mdadm. Not that any entries beyond /dev/dm-# and /dev/md# would not already be done by udev and so in a sense be independent of the driver. On the other hand human assumption is that /dev/mapper/* is something defined by device-mapper. So this could cause confusion there... > > 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) I would say yes, as this is advised by Intel (for IMSM at least) and dmraid really is not maintained that well. As to the how, I believe there have been good proposals already. Not sure the current approach of mdadm to name things /dev/md/Volume#... is completely safe either. I am not sure the "Volume#" part is controllable, so multiple containers could have the same name. Having /dev/mapper/* names in fstab also is not foolproof as, at least in theory, one may add a disk with the same VG name (and same LV names). So I would think that converting /dev/mapper/isw_* should at least not make matters worse than before. If it were not for unattended upgrades maybe a check with a warning could be made in case of duplicate uuids found... For cases where the RAIDed drive is just used as a PV for LVM, nothing needs to be done, but at least in that case there is no "isw_" name in fstab anyway. And /boot at least traditionally tended to be constructed outside the RAID. > > 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. >
signature.asc
Description: OpenPGP digital signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
