Comment 9 for bug 2039719

Updating with more information about testing. This is the information provided by the original reporter for this issue:

From a high level we ultimately ran tests that were periodically (approx every 5 mins) mounting volumes by creating new multipath entries and /dev/dm-X entries then these would get torn down after use (involved importing ~28GB of data for each volume).

Along side those tests we were running scripts that were checking for entries on the output of "multipath -ll" that aligned with the format:

3600a098038305768315d5650546f5472 dm-55 ##,##
size=28G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- #:#:#:# - #:# failed undef unknown
| `- #:#:#:# - #:# failed undef unknown
`-+- policy='service-time 0' prio=0 status=enabled
  |- #:#:#:# - #:# failed undef unknown
  `- #:#:#:# - #:# failed undef unknown

We effectively performed A,B,A testing in that we first confirmed we were seeing the problem multipath entries in multipath-tools_0.8.3-1ubuntu2.1 & kpartx_0.8.3-1ubuntu2.1 then we cleaned out all error entries then upgraded to the new versions (multipath-tools_0.8.3-1ubuntu2.3 & kpartx_0.8.3-1ubuntu2.3) and allowed them to run for roughly 5 days and confirmed we were no longer seeing the error entries. Once that ran for a bit we then reverted back to the original multipath-tools and confirmed we were seeing error entries again.