[parted-devel] "linux: use devicemapper task name instead of device node name" causes dmraid breakage

[Hans de Goede]

Hi,

On 05/17/2010 12:35 AM, Phillip Susi wrote:
> I have traced a severe regression in Ubuntu 10.04 for the commit with
> the title in the subject.  The finger print is 162ac17e.  This change
> caused a 'p' to be inserted into the dev node for partitions on dmraid
> devices, but dmraid does not use the p, and partman does not expect
> there to be a p, so it could not find the device after creating it.
>
> For now I have reverted this patch in Ubuntu to resolve the issue, but
> I'm not sure that is the best solution given that I do not fully
> understand the purpose of this change.  Perhaps Hans could explain it a
> bit further and reason out the correct way to fix it.
>

With newer lvm2 versions the files under /dev/mapper are no longer created
by the lvm tools, but by udev (as they should be). As a consequence they
are no longer device nodes but symlinks.

IOW /dev/mapper/foo no longer is a device node, but a symlink to ie
/dev/dm-0

As parted resolves symlinks before operating on them this means that
new partitions on /dev/mapper/foo would be named /dev/mapper/dm-0p#

So the patch you blame for the regression you are seeing changes the
code to determine the name for the partition mapping to use the
devicemapper name (which is the foo part of /dev/mapper/foo)
of the devicemapper node operated on rather then the devicenode name
(/dev/dm-0).

Note that before this change the partition name would be
/dev/mapper/dm-0p#

IOW the p is still there, the code before this patch called
_device_get_part_path to determine the partition name, and that has
the following snippet in it:

         } else if (dev->type == PED_DEVICE_DAC960
                         || dev->type == PED_DEVICE_CPQARRAY
                         || dev->type == PED_DEVICE_ATARAID
                         || dev->type == PED_DEVICE_DM
                         || isdigit (dev->path[path_len - 1]))
                 snprintf (result, result_len, "%sp%d", dev->path, num);

Notice the p in the format string. The new code does not change
this behavior, as the code in question only operates on devices
with a type of PED_DEVICE_DM, and thus the new code always
inserts the p.

So if reverting this patch results in parted creating partitions
without an extra p in the name, then that means that Ubuntu's parted
is carying a patch changing the behavior of _device_get_part_path()

Note that upstream dmraid (the cmdline tool), will by default also
create devicemapper mappings for partitions when activating a
RAID set, and these mappings also have a p in the name.

Likewise kpartx (which one should use rather then dmraid's build
in partition code as kpartx can handle gpt labels too and dmraid
cannot), also creates partition mappings with a p in the name
by default.

Thus if partman expects there to be no p in the name, and other tools
in Ubunutu don't add the p when activating partitions during boot, then
that means that Ubuntu is deviating from various upstreams here (3 to
be precise) all 3 of which are kept in careful sync wrt their behavior
when it comes to partition names. And the fix here is not to revert
this patch, but to drop the patches from the Ubuntu packages in
question so that they are not unnecessarily deviating from upstream,
and to fix partman to expect the p in the partition device node name.

Note that a p in the device node name will also happen for partitions
on compaq smart array controllers (cciss) and partitions on
mdraid devices to name a few, and in this case the p is added by
the kernel itself.

Feel free to quote (parts of) this mail in launchpad, or where ever
you are going to further pursue this issue.

Regards,

Hans

p.s.

If you're going to file a launchpad but about this, can you please
mail me the link so that I can follow it?