-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJTCy+4AAoJEOhnXe7L7s6jerkP/0x5MjrcBmlAbwjUaIxc6vP9
WBJkxSbpyxxzinNsns2nPOStqB9NRuf3I5y6egDIFZhwUh5eXYiZo9fKDkqHlZs5
l2bKMOQu0LZNe//+61iBvkVIF3NBi7qlKtSH4Qkc/0x7TfviTJEZgxCuRz7xrD4Q
NmlgV7B7g6GqdjKwuEZ5qlWlHruNGjQczr9+lOIdS62BUloqmWMeytCO8haDp8OR
4OaWNJani0m4/My19gGmeM8KFToQWEzmKkOYSoY2fMCoXLq8AaxsC4Qb7RIgLLcp
15jeVAWEcy1HXvT9T6AxS/Hxp1SK3DspJt1ewp3q4I0t+ZvaScmlRsgQGhcXsnTg
4KeJ0C6DIxYPE975do+Uq08dzBMyf/zAEx9wdFlHTWrwZO7HrtLTqlz1GGgZd43p
LFsP4r4utYzCRQJgfyChzeF6avBY8mqGWxy6ioBnPBxBnp/eLg/V3xHhCKgjLHt9
qV01N0D4mVo8oOpJFwAbx/Ga+Cq4CFCMK3cfUcbzOKaF8uvAJa1nG+/43g4wop5n
FVZYdOqe3IrLjsqBuCp8ntHDmkeBbFVIEyOu+f9VcZP5tdAqApd7+GWYryV2bPpT
bMxebfdSiNsnLB+u3EricOjTC040zy2974vMB3Fl5+BrvOjpPx7qPaMF3GfCZmRd
YWu7M9z2TDsD81YPjsa1
=vw2D
-----END PGP SIGNATURE-----
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.
>
