Re: fc transport creates second set of targets for devices in an "md"

James Bottomley
2006-06-09T19:23:34Z

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