Hi, I am exploring the 2.6.27 linux scsi mid layer and I have a few questions. I have code access and can browse reasonably, so you can refer to functions and files. I would like to know how each of the Host Channel TargetId and LUN are enumerated and assigned to each SCSI device. In case, the scsi device is on a storage array, can the TargetId and LUN values change for a LUN? Specifically, during path failures to an FC array, is it possible to get a different value of TargetId and LUN id for a SCSI device when it reappears when the paths recover? Some code reading has led me to believe that the each remote port is being viewed as a separate (Target) ID. Why is this so? Dont we recognize multiported target SCSI devices? I have also seen that during remote port time out(possibly due to path failures or fabric problems), the remote port related data is not discarded. When the remote port is detected by the LLDD, scsi_transport_fc compares it with the list of ports it has and re-assigns the same state/structure to the newly discovered port. Why was this required? Is it to prevent target ID changes across loss of connectivity to the (fibre channel) target device? If HBAs are hotpluggable/hot swappable, will the 'host' part of the [H,C,I,L] tuple change for a new identical HBA plugged into the same slot? How are LUN Ids enumerated? Does the order in which the response REPORT_LUN command gives LUNs, determine the LUN ID assignment for a SCSI disk discovered on a remote target on an array connected via FC? Can this order of LUN presentation change and is valid? If REPORT LUNs is not supported and the scsi_transport_fc has to scan all possible LU ids, the order is fixed(1 - 2^16). Is this why the LUN id does not change for a particular LUN being presented to a host across rescans/path-failure-recovery cycles? Thanks in advance, Dheeraj -- Simplicity of character is the natural result of profound thought. -- To unsubscribe from this list: 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
