Re: correct deregistration from scsi_transport_fc
On Mon, Aug 29, 2005 at 12:02:15PM +0200, Andreas Herrmann wrote: On 29.08.2005 10:48 Christoph Hellwig [EMAIL PROTECTED] worte: Never use scsi_add_device with the fc_transport code. fc_remote_port_add will do a proper lun scan if the added rport is a scsi target. Won't work for all zSeries FC host adapters because they are virtualized and you can have several virtual adapters using the same WWPN/WWNN. Using LUN masking and zoning it is not possible to configure the SAN such that one virtual adapter sees just that LUNs that are supposed to be used by it. There is a tool to write an access control table to the adapter. This ACT specifies which virtual adapter can access which ports and FCP LUNs ... Ugly. Maybe we could pass down a bitmap of exluded luns down the scanning path? Starting from fc_rport_create down to scsi_scan_target and the underlying fuctions? - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: correct deregistration from scsi_transport_fc
On Mon, Aug 29, 2005 at 05:27:47PM +0200, Andreas Herrmann wrote: It works by accident, but I will veto any updates you're going to send for this broken behaviour. So scsi_add_device will soon be mentioned in Documentation/feature-removal-schedule.txt? No, the will still be available for transport where they make sense, aka non-SAM things like RAID adapters. What is the rationale of proscribing usage of scsi_add_device() when scsi_transport_fc is used? We do actually use it inernally in the sysfs scan attribute. We don't want the driver to do their own LUN scanning, though - that's the job of the generic scsi code. That's intentional. See the discussion during development of the FC transport class. I don't like that behaviour but it's a compromise we agreed on. Where is the function to remove the scsi target representation of an rport? You did not agree on having memory leaks in the kernel, did you? fc_remove_host will remove it when the host is gone. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: correct deregistration from scsi_transport_fc
On Mon, Aug 29, 2005 at 10:38:17AM +0200, Andreas Herrmann wrote: Hi, What is the correct sequence to register and deregister host/rport/scsi_devices at the scsi stack? ZFCP's sequence is like follows: scsi_add_host fc_remote_port_add (if port succesfully configured/opened in/by zfcp) scsi_add_device (if unit successfully configured/opened in/by zfcp) Never use scsi_add_device with the fc_transport code. fc_remote_port_add will do a proper lun scan if the added rport is a scsi target. If a zfcp-adapter is set offline I do the following to get rid of the entries within /sys/class/fc_*: fc_remote_port_delete (for each rport registered for this adapter) fc_remove_host scsi_remove_host fc_remove_host removes all rports for you. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: correct deregistration from scsi_transport_fc
On 29.08.2005 10:48 Christoph Hellwig [EMAIL PROTECTED] worte: Never use scsi_add_device with the fc_transport code. fc_remote_port_add will do a proper lun scan if the added rport is a scsi target. Won't work for all zSeries FC host adapters because they are virtualized and you can have several virtual adapters using the same WWPN/WWNN. Using LUN masking and zoning it is not possible to configure the SAN such that one virtual adapter sees just that LUNs that are supposed to be used by it. There is a tool to write an access control table to the adapter. This ACT specifies which virtual adapter can access which ports and FCP LUNs ... A REPORT LUNs scan from adapter X of port Y might report thousands of LUNs that I don't like to use with adapter X because they are for another virtual adapter. Thats the reason why I like to stick to manual configuration (triggered from zfcp) of scsi_devices. Hence zfcp has not enabled a proper lun scan when fc_remote_port_add is called. slave_alloc will fail for scsi_devices not added by zfcp itself. (BTW, new FC cards that are already announced will provide a feature called NPort Id Virtualization. With this feature each virtual adapter will have its own WWPN. This will allow zfcp to use the lun scan during fc_remote_port_add.) Do you mean, that scsi_add_device is not supposed to work with fc_transport code anymore? Or is it mere a recommendation not to stick to scsi_add_device but to use the automatic LUN scanning provided with fc_transport code? fc_remove_host removes all rports for you. Ok, works. But it still fails to remove the scsi target representation of that rport. Regards, Andreas - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: correct deregistration from scsi_transport_fc
On Mon, Aug 29, 2005 at 12:02:15PM +0200, Andreas Herrmann wrote: On 29.08.2005 10:48 Christoph Hellwig [EMAIL PROTECTED] worte: Never use scsi_add_device with the fc_transport code. fc_remote_port_add will do a proper lun scan if the added rport is a scsi target. Won't work for all zSeries FC host adapters because they are virtualized and you can have several virtual adapters using the same WWPN/WWNN. Using LUN masking and zoning it is not possible to configure the SAN such that one virtual adapter sees just that LUNs that are supposed to be used by it. There is a tool to write an access control table to the adapter. This ACT specifies which virtual adapter can access which ports and FCP LUNs ... That's totally broken. most FC sans have zoning and access control, but this is by no way a feature of the HBA. Your feature is totally broken, different from other FC setups and must go away. A REPORT LUNs scan from adapter X of port Y might report thousands of LUNs that I don't like to use with adapter X because they are for another virtual adapter. So what? That's the same as for every FC SAN, and it is nessecary to support proper managment applications. Thats the reason why I like to stick to manual configuration (triggered from zfcp) of scsi_devices. Hence zfcp has not enabled a proper lun scan when fc_remote_port_add is called. slave_alloc will fail for scsi_devices not added by zfcp itself. (BTW, new FC cards that are already announced will provide a feature called NPort Id Virtualization. With this feature each virtual adapter will have its own WWPN. This will allow zfcp to use the lun scan during fc_remote_port_add.) Do you mean, that scsi_add_device is not supposed to work with fc_transport code anymore? It works by accident, but I will veto any updates you're going to send for this broken behaviour. fc_remove_host removes all rports for you. Ok, works. But it still fails to remove the scsi target representation of that rport. That's intentional. See the discussion during development of the FC transport class. I don't like that behaviour but it's a compromise we agreed on. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: correct deregistration from scsi_transport_fc
There is a tool to write an access control table to the adapter. This ACT specifies which virtual adapter can access which ports and FCP LUNs ... That's totally broken. most FC sans have zoning and access control, but this is by no way a feature of the HBA. Your feature is totally broken, different from other FC setups and must go away. We know. We fixed it with the latest machine generation and corresponding HBA (IBM System z9). The solution is N_Port Identifier Virtualization (NPIV, see recent FC standard documents), i.e. a SAN identity for each virtual HBA. However, there will be older machines with older HBA's around for some time. We will have to cater for those as well. A REPORT LUNs scan from adapter X of port Y might report thousands of LUNs that I don't like to use with adapter X because they are for another virtual adapter. So what? That's the same as for every FC SAN, and it is nessecary to support proper managment applications. Correct. But there is another problem inherent in this setup. Without NPIV, we can't share access to the same LUN, e.g. LUN 0, through virtual HBAs hosted by the same physical HBA, in order to avoid several issues as to SCSI compliance (sense data delivery, reserve/release, abort task set, mode pages changes, etc.). That is why, we require manual setup of LUNs to be accessed through sysfs, so far. It is desirable to go with REPORT LUNs for NPIV-capable virtual HBAs, while keeping some compatability code in zfcp for non-NPIV virtal HBAs. Martin Peschke |-+ | | Christoph Hellwig| | | [EMAIL PROTECTED] | | | Sent by: | | | [EMAIL PROTECTED]| | | .kernel.org | | || | || | | 29/08/2005 13:03 | | || |-+ ---| | | | To: Andreas Herrmann/Germany/[EMAIL PROTECTED] | | cc: Christoph Hellwig [EMAIL PROTECTED], James Bottomley [EMAIL PROTECTED], Linux SCSI| |linux-scsi@vger.kernel.org, [EMAIL PROTECTED] | | Subject: Re: correct deregistration from scsi_transport_fc | | | ---| On Mon, Aug 29, 2005 at 12:02:15PM +0200, Andreas Herrmann wrote: On 29.08.2005 10:48 Christoph Hellwig [EMAIL PROTECTED] worte: Never use scsi_add_device with the fc_transport code. fc_remote_port_add will do a proper lun scan if the added rport is a scsi target. Won't work for all zSeries FC host adapters because they are virtualized and you can have several virtual adapters using the same WWPN/WWNN. Using LUN masking and zoning it is not possible to configure the SAN such that one virtual adapter sees just that LUNs that are supposed to be used by it. There is a tool to write an access control table to the adapter. This ACT specifies which virtual adapter can access which ports and FCP LUNs ... That's totally broken. most FC sans have zoning and access control, but this is by no way a feature of the HBA. Your feature is totally broken, different from other FC setups and must go away. A REPORT LUNs scan from adapter X of port Y might report thousands of LUNs that I don't like to use with adapter X because they are for another virtual adapter. So what? That's the same as for every FC SAN, and it is nessecary to support proper managment applications. Thats the reason why I like to stick to manual configuration (triggered from zfcp) of scsi_devices. Hence zfcp has not enabled a proper lun scan when fc_remote_port_add is called. slave_alloc will fail for scsi_devices not added by zfcp itself. (BTW, new FC cards that are already announced will provide a feature called NPort Id Virtualization. With this feature each virtual adapter will have its own WWPN. This will allow zfcp to use the lun scan during fc_remote_port_add.) Do you mean, that scsi_add_device is not supposed to work with fc_transport code anymore? It works by accident, but I will veto any updates you're going to send for this broken behaviour. fc_remove_host removes all rports for you. Ok, works. But it still fails to remove the scsi target representation of that rport. That's intentional. See
Re: correct deregistration from scsi_transport_fc
On 29.08.2005 13:03 Christoph Hellwig [EMAIL PROTECTED] wrote: Won't work for all zSeries FC host adapters because they are virtualized and you can have several virtual adapters using the same WWPN/WWNN. Using LUN masking and zoning it is not possible to configure the SAN such that one virtual adapter sees just that LUNs that are supposed to be used by it. There is a tool to write an access control table to the adapter. This ACT specifies which virtual adapter can access which ports and FCP LUNs ... That's totally broken. most FC sans have zoning and access control, but this is by no way a feature of the HBA. Your feature is totally broken, different from other FC setups and must go away. Of course, also in my opinion this is not the optimal way to virtualize adapters. But that is how the hardware works. I cannot change this. zfcp just can exploit the hardware as is. And therefor zfcp needs for compatibility reasons the scsi_add_device interface. A REPORT LUNs scan from adapter X of port Y might report thousands of LUNs that I don't like to use with adapter X because they are for another virtual adapter. So what? That's the same as for every FC SAN, and it is nessecary to support proper managment applications. The main point is that we do not want that all LUNs that are reported by REPORT LUNS are configured for the virtual adapter. I think Martin Peschke gave you further information about this. BTW, are there any proper management applications for Linux (all architectures, based on which interface)? Thats the reason why I like to stick to manual configuration (triggered from zfcp) of scsi_devices. Hence zfcp has not enabled a proper lun scan when fc_remote_port_add is called. slave_alloc will fail for scsi_devices not added by zfcp itself. (BTW, new FC cards that are already announced will provide a feature called NPort Id Virtualization. With this feature each virtual adapter will have its own WWPN. This will allow zfcp to use the lun scan during fc_remote_port_add.) Do you mean, that scsi_add_device is not supposed to work with fc_transport code anymore? It works by accident, but I will veto any updates you're going to send for this broken behaviour. So scsi_add_device will soon be mentioned in Documentation/feature-removal-schedule.txt? What is the rationale of proscribing usage of scsi_add_device() when scsi_transport_fc is used? fc_remove_host removes all rports for you. Ok, works. But it still fails to remove the scsi target representation of that rport. That's intentional. See the discussion during development of the FC transport class. I don't like that behaviour but it's a compromise we agreed on. Where is the function to remove the scsi target representation of an rport? You did not agree on having memory leaks in the kernel, did you? Regards, Andreas - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
