I've been trying to understand what the default behavior should be if
no_path_retry is not set in the multipath.conf file. The annotated
version describes (somewhat) what happens with values of queue, fail, or
n>0, but says the default is NULL, and does not say what behavior NULL
produces.
The reason for the question is a situation where a highly-available
iscsi target undergoes failover from one node to another, and the iscsi
initiators see all their multiple paths fail during that transition
time, which takes 5-120 seconds. I had set no_path_retry to queue,
thinking it would queue until the paths come back, but it seems to stop
checking the path status and queue forever. Is that expected? Or
should no_path_retry=queue stop queuing (but continue checking the
paths) and send both queued and new requests when the paths are
available again? With it set to queue it hangs all I/O requests until I
restart multipathd, at which point I expect that all queued data is
lost. It will stay in the queued state for hours/days even though the
paths are back if no action is taken.
This is on fedora 9, the default device-mapper-multipath rpm, version
0.4.7, release 16.fc9. path_checker=readsector0, and poling_interval=10.
Thanks for helping me understand what is happening here.
-Ty!
--
-===========================-
Ty! Boyack
NREL Unix Network Manager
ty@xxxxxxxxxxxxxxxxxx
(970) 491-1186
-===========================-
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
