On Fri, 2006-06-09 at 11:35 -0500, Michael Reed wrote: > In this instance, there was no i/o in progress so the mid-layer didn't > take the device off line. It was simply removed by the transport. Oh, OK, it's as mike said then ... we end up with a transport disconnect and the openers of the device are left with a reference that simply fails all I/O until they close it. > > Basically, when a path goes dead it's up to the multi-path user level to > > remove it an wait for udev to inform it that another SCSI node has > > appeared and has the correct signature to be another path to the device. > > Are there notification mechanisms in place such that a driver which has > the device opened (claimed?) will be notified upon it's removal? Should > there be? Could it happen via a driver callback? Udev? Both? > I like the idea of a callback so that the removal has a chance of being > complete. Well, yes, there was an event sent, at least a kobject remove event for the device which could have been picked up by udev or anything else listening. > Is it possible to do a better job of reconnecting a removed target > to an open sd? Not really, and that's by choice. What constitutes removal, and what action should be taken on it (and even how you recognise the same device returning) are pretty much policy issues to be sorted out at user level. We do allow the transports to set a local remove policy (as FC does with the devloss timer) but since you explicitly defeated that, you get into the user arena. James - : 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
