On Tue, 2026-10-06 at 23:07 +0200, Martin Wilck wrote: > Have you tested this, and have you observed cases where it actually > helped to resume a device after the first DM_DEVICE_RESUME had failed? > > Would it increase the chances to resume the device if we wait a few > fractions of a second before retrying?
Thanks Martin, you're right to push on this. Our fault injector was written to reproduce the exact sequence we observed in the field: DM_DEVICE_REMOVE returned -EBUSY, and the following status query then failed. So the injector deliberately forces just those two -- DM_DEV_REMOVE -> EBUSY and the next DM_TABLE_STATUS -> error -- which is what drives dm_is_mpath() to return -1. It does not force DM_DEVICE_RESUME to fail, so the retry branch added in 2/2 was never actually exercised. As a result I can't claim to have observed the second resume help. The extra retry was purely defensive, in case the resume ioctl itself failed, and I agree an immediate identical retry with no delay wouldn't add much. On this no-table-swap resume the realistic failures (-EINVAL "not suspended", -ENXIO "gone") already mean the map isn't left suspended, so neither a retry nor a short delay buys much. So I'll drop 2/2. Patch 1/2 is the real fix for the problem we hit in our environment. If it's useful, I can add a condlog(1, ...) warning when the resume ioctl fails, so a leaked suspend is at least visible in the logs -- would that address your concern? If you agree, should I resend patch 1/2 on its own as a v2 (with 2/2 dropped)? Please confirm. Regards, Suresh
