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