On Thu, 2024-04-25 at 19:35 -0400, Benjamin Marzinski wrote: > Currently multipath makes sure that dev_loss_tmo is at least as long > as > the configured no path queueing time. The goal is to make sure that > path > devices aren't removed while the multipath device is still queueing > in > hopes that they will become usable again. > > This is racy. Multipathd may take longer to check the paths than > configured. If strict_timing isn't set, it will definitely take > longer. > To account for this, pad the minimum dev_loss_tmo value by five > seconds > (one default checker interval) plus one second per minute of no path > queueing time.
What's the rationale for the "one second per minute" part? It feels kind of arbitrary to me, and I don't find it obvious that we need larger padding for larger timeouts. Regards Martin
