[dm-devel] [PATCH 0/7] Fix muitpath/multipathd flush issue

Martin Wilck martin.wilck at suse.com
Wed Jul 1 20:54:34 UTC 2020


On Thu, 2020-06-18 at 18:06 -0500, Benjamin Marzinski wrote:
> 
> I uploaded the test program, aio_test:
> 
> https://github.com/bmarzins/test_programs.git
> 
> You just need to run in on a queueing multipath device with no active
> paths and an open count of 0. It will hang with the device open.
> Restore
> a path, and it will exit, and the open count will go to 0.

Tried it now, it behaves as you say. I admit I can't imagine how the
suspend/resume would improve anything here. Indeed, as you say, it opens 
up a race window. Another process might open the device while
it's suspended. Worse perhaps, once the device is resumed, an uevent will be 
generated, and stacked devices might (in principle at least) be recreated
before we get down to flush the map.

MAYBE the suspend/resume was necessary in the past because some earlier 
kernels wouldn't immediately fail all outstanding commands when 
queue_if_no_path was deactivated? (just speculating, I don't know if this
is the case).

Regards,
Martin

-- 
Dr. Martin Wilck <mwilck at suse.com>, Tel. +49 (0)911 74053 2107
SUSE  Software Solutions Germany GmbH
HRB 36809, AG Nürnberg GF: Felix
Imendörffer







More information about the dm-devel mailing list