> 2) If so, have you considered trapping loop up/down events to handle
> such a case? Real users of multipath tech do not want to wait 90s for
Generally it fails a path when we get a path specific error; it fails the
IO if we get a device (i.e. logical unit) error. If there are no paths
available, the IO is failed (though this could be changed to be
Behaviour on a cable removal is fibre, adapter, and adapter drive specific
- the qla driver has some sort of timeout on a port down that can be
lowered. It (fibre channel) can immediately complete (with failure) an
outstanding IO on a port down (or SCN notification). loop attached does
not always give you notification.
So with loop attached (AFAIK) you still might have to wait for a timeout
if you yank a disk.
Timeouts are the hardest to deal with - since we don't know where the
error occurred, so generally should not fail the IO (or path).
If we had user scanning, and some sort of hotplug for targets coming and
going, those be used to add and remove (or just fail) paths (at least for
-- Patrick Mansfield
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/