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

[Michael Reed <mdr@sgi.com>]

James Bottomley wrote:
> On Thu, 2006-06-08 at 14:13 -0500, Michael Reed wrote:
>> I created an md device on two fibre channel disks, sde and sdf.
>> I then disabled the switch port to which the hba is connected.
>> After the remote port time out messages, I re-enabled the switch
>> port.  Three things happen that are weird.  First, two unexpected
>> responses while scanning.  Second, the creation of sdm and
>> sdn.  Third, the md device remains inaccessible.
> 
> This is sort of as expected.  What you did was wait out the reconnection
> timer, so the mid layer failed and offlined the devices.  Thus, when
> they come back, they get new instances.  If you'd done a remove-device
> after they went offline, they'd have come back to the same location (as
> long as nothing had them open).  But this is user level stuff.

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.

> 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.

Is it possible to do a better job of reconnecting a removed target
to an open sd?

Thanks,
 Mike

> 
>> I don't think this is working the way it's intended to.  I
>> suspect it will cause big problems for multi-path volume managers
>> in a fail back situation.
> 
> James
> 
>