On Thursday, April 21, 2005 3:55 PM, Lars Marowsky-Bree wrote: > Together with the "queue_if_no_path" feature flag for dm-mpath that > should do what you need to handle this (arguably broken) array > behaviour: It'll queue until the error goes away and > multipathd retests > and reactivates the paths. That ought to work, but given that I don't > have an IBM ESS accessible, please confirm that. Depending on the "queue_if_no_path" feature has the current undesirable side-effect of requiring intervention of the user space multipath components to reinstate at least one of the paths to a useable state in the multipath target driver. This dependency currently creates the potential for deadlock scenarios since the user space multipath components (nor the kernel for that matter) are currently architected to avoid them. I think for now it may be better to try to avoid having to fail a path if it is possible that an io error is not path related. - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
