[dm-devel] Questions around multipath failover and no_path_retry

Karan Vohra karanvohra at outlook.com
Sun Mar 11 16:47:17 UTC 2018


Hi Folks,

Let us assume, there are 2 paths within the path group which dm-multipath is sending the I/Os in round-robin fashion. Each of these paths are identified as unique block device(s) such as /dev/sdb and /dev/sdc.

Let us say some I/Os are sent over to the path /dev/sdb and either the requests time out or there is a failure on that path, what happens to those I/Os? Are they sent over to the other path - /dev/sdc or does dm-multipath waits for /dev/sdb to come back online and only sends I/O to /dev/sdb? One of the reasons we are concerned about the above scenario is- let us say there is a write I/O W1 which is routed to /dev/sdb and then there is a failure. There was a write I/O W2 which wrote at the same block via /dev/sdc. Now if multipath sends W1 through /dev/sdc, W2 gets overwritten by W1. The expectation was that W2 happens after W1 and should overwrite W1 but the result is opposite. Situations like these can cause data inconsistency and corruption.We were thinking of using no_path_retry configuration to be set to queue to make sure that the I/Os supposed to be going to path1 never make it to path2. But the question is that would not that cause unexpected behavior in application layer? Let us say there are I/O Requests R1, R2, R3 and so on.. R1 is going to Path1, R2 is going to Path2 and so on. If Path1 dies for some reason, with the setting of no_path_retry to queue, queueing will not stop until the path is fixed so does not that mean that R1, R3,R5 ... will not make it to block device until the path is fixed? Would it not cause failures if the issue persists for seconds? What about the size of queue? Is there any danger of queue getting overloaded?Any pointers or references would be of great help.

Thanks!
Karan


Get Outlook for Android<https://aka.ms/ghei36>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20180311/8e6a2726/attachment.htm>


More information about the dm-devel mailing list