On Tue, May 08, 2007 at 11:00:11AM -0400, James Smart wrote: > Curious why you are calling scsi_scan_target() or > scsi_target_block()/scsi_target_unblock() directly. I would have > thought the add/remove rport code would have done this for you, > and it deals with all the flush conditions, etc. fc_remote_port_add issues a scsi_scan_target with SCAN_WILD_CARD. This tries to get all LUNs for the target via REPORT LUNS for LUN 0. The current design for zfcp is to prevent the wildcard scan from the SCSI layer by not allocating a device for LUN 0. When a FCP adapter does not support NPIV, the adapter can still be shared among multiple Linux systems. Each Linux system can access different LUNs, that are activated manually via sysfs. So, the wildcard scan from the FC transport class does nothing and zfcp activates the LUNs it wants to use via direct calls to scsi_scan_target. If every adapter would support NPIV, zfcp could rely on the scan by the FC transport class, unfortunately, this is not the case. Christof Schmitt - 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
