James Smart wrote: > 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. I'll capture data and post later today. > > 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. Agree. Sometimes the title is used to draw attention to a problem. ;) It worked. > > 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. So, do any volume managers work correctly now? By "correct" I mean, when the device returns, will they be able to access it? > > I do have a request to make an option for the transport to not remove > the devices upon disconnect. I understand why. If this does what I suspect it will, please add SGI to the list. We should probably discuss requirements. Mike > > -- 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
