On Wed, 2026-10-07 at 07:16 +0000, Suresh Thelkar wrote: > 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.
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? > 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. > 09:17 multip > 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? Yes, that makes sense. We should see this in the logs. > If you agree, should I resend patch 1/2 on its own as a v2 (with 2/2 > dropped)? Please confirm. Yes, please resend a final version. It's up to you whether you keep two commits or squash them into one. Martin -- Dr. Martin Wilck <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstr. 146, 90461 Nürnberg, Germany Geschäftsführer: Stefan Gaiser, Jochen Jaser, Abhinav Puri (HRB 36809,AG Nürnberg)
