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

[Mike Christie <michaelc@cs.wisc.edu>]

Michael Reed wrote:
> 
> Mike Christie wrote:
>> 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.
>>>
>>> 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.
>>>
>> Even if the rport is removed and the devices under it are removed, md
>> can still have a reference to the device so the memory does not
>> disappear on it (MD still thinks the device is there but scsi says it is
>> gone basically). Because of this, when you plug in the cable again and a
>> new rport is created sd.c can end up allocating another sdX value.
>>
> 
> So, how about a callback to the driver, md, with the reference so that it
> can release said reference?
> 

Look at how DM's userspace multipath tools handle this. Last I looked it
could handle the hotplug events that are fired when a scsi device is
removed or added so as long as you set something like queue_if_no_path
or no_path_retry high enough then it could work.