> I did not see an answer to this issue. I am also hitting the problem > (i.e., devices being removed) during some dm-mp port bounce testing. > Is this the correct behavior going forward for the fc transport? Current design is when the LLDD tells the transport that the port is gone, it (and it's subtree) gets deleted. Right or not ? don't know. I would assume having the real state, where it does not exist if not present, is the right overall approach. Also makes it consistent with other storage devices that go away when not connected (usb sticks, etc). > Also I see a difference in behavior between the lpfc and > qla2xxx drivers > where the lpfc is not removing target even though the > "rport-5:0-5: blocked > FC remote port time out: removing target" message is printed. > I guess I > can look into the difference myself, but I thought Andrew or > James S you > two would know. I'll have to look into things. Likely this is a reference count issue, and may be a reference count on a sdev. I doubt lpfc does anything relative to this scenario, but I'll check. The drivers could also differ on the return codes returned when the rport is in this transition state, which may affect the sdev/block device and references. Keep in mind there are issues in .12 if the target is torn down. There was some recent patches to correct this. http://marc.theaimsgroup.com/?l=linux-scsi&m=111845669410785&w=2 -- james s - : 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
