On 7/3/25 2:09 AM, Christoph Hellwig wrote:
I'm still very doubtful on this whole approach, and I think you are
ignoring the root cause, which is dm-multipath keeping a q_usage_count
reference for an unbounded time. It is only supposed to be held over
I/O, and I/O is expected to time out.
No. Since queue_if_no_path was introduced, it can queue I/O
indefinitely. The oldest reference I could find to the queue_if_no_path
implementation is from 20 years ago:
Author: Alasdair G. Kergon <agk@xxxxxxxxxx>
Date: Wed Mar 9 17:19:15 2005 -0800
[PATCH] device-mapper: multipath
The core device-mapper multipath and path-selector code.
[ ... ]
As a last resort there is an option to 'queue_if_no_path' which
queues I/O if
all paths have failed e.g. temporarily during a firmware update or
if the
userspace daemon is slow reinstating paths.
You'll probably get much farther by changing dm-multipath to not hold
a q_usage_count reference for something not actually under I/O.
Please make yourself familiar with how the dm-mpath driver works. The
default behavior for the dm-mpath driver is to operate in request based
mode (DM_TYPE_REQUEST_BASED). Hence, a request is allocated before the
dm-mpath driver sees any I/O. Hence, q_usage_counter is increased before
the dm-mpath driver sees any I/O. Hence, what has been suggested cannot
be implemented.
Bart.
