On Wed, 2026-10-07 at 09:22 +0200, Martin Wilck wrote:
> Have you ever found out what the exact reason for the DM_TABLE_STATUS
> failure was? What was the return code of the kernel / device-mapper?
> Can we perhaps make dm_is_mpath() smarter?
Honestly, no -- we never captured the exact errno of the failing
DM_TABLE_STATUS ioctl in the field. The diagnosis came from the vmcore
and journal, which showed the leaked-suspend symptom together with the
LUN-recycling + ALUA storm, but not the return code of the status ioctl
itself. Our fault injector used EIO as a representative transient
failure rather than a measured one, so I can't give you the kernel's
actual value from the incident.
On making dm_is_mpath() smarter: on current master it already
distinguishes the cases via libmp_mapinfo__(). An ENXIO from the ioctl
(and a !dmi.exists result) maps to DMP_NOT_FOUND -> DM_IS_MPATH_NO
("genuinely gone"), and a target-type mismatch to DMP_NO_MATCH ->
DM_IS_MPATH_NO. Only a non-ENXIO ioctl failure becomes DMP_ERR ->
DM_IS_MPATH_ERR. So the "device is gone" case is already handled; what
reaches DM_IS_MPATH_ERR is a genuinely ambiguous failure where we can't
tell whether the map is still present and suspended. Without the real
errno I'd rather not reclassify any of those as "removed" -- that is
exactly the misclassification patch 1 removes. If we later capture a
specific, reliably-benign errno there, we can special-case it then.
I'll send v2 shortly (patch 1 unchanged + a condlog(1) on resume
failure).
Thanks,
Suresh
