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

[James Smart <James.Smart@Emulex.Com>]

The data that would be most interesting is a recursive listing of the
device via the /sys/devices tree.  This would show the host, rports,
targets, and sdevs.  Getting a copy of this both before, when missing,
and after they are reconnected. The additional contents to look at
is : contents of /sys/class/fc_remote_ports.

Also - it's unlikely that FC is to blame here. The above data would
show whether we had the same WWN's, reused target id's or not, and
what the midlayer reassigned to h/c/t/l's. It would show if the FC
transport is in error or not.

Relative to volume managers - yes, they have some difficulty. However,
the tact they plan on taking is to bind the device based on the udev
name that get built on it. Which means - md would have issues, but DM
is planning for it.

I do have a request to make an option for the transport to not remove
the devices upon disconnect.

-- james

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