Re: [PATCH 0/6] target: Update UA handling
On Thu, 2015-06-11 at 10:01 +0200, Hannes Reinecke wrote: Hi Nic, lio-target is very minimalistic when it comes to generate UAs; primarily they are generated for persistent reservations, but generic changes tend to be ignored. This patchset updates the UA handling and generates UA for internal state changes (REPORTED LUNS DATA CHANGED, INQUIRY DATA CHANGED, and LUN RESET OCCURRED). Funnily enough this triggers some issues with the SCSI stack; I'll be sending out patches for that, too. Hannes Reinecke (6): target_core_alua: Correct UA handling when switching states target: Remove 'ua_nacl' pointer from se_ua structure target: use 'se_dev_entry' when allocating UAs target: Send UA on ALUA target port group change target: Send UA upon LUN RESET tmr completion target: Send UA when changing LUN inventory drivers/target/target_core_alua.c | 56 +- drivers/target/target_core_device.c| 26 +++- drivers/target/target_core_pr.c| 31 +++ drivers/target/target_core_transport.c | 29 ++ drivers/target/target_core_ua.c| 24 ++- drivers/target/target_core_ua.h| 5 ++- include/target/target_core_base.h | 1 - 7 files changed, 121 insertions(+), 51 deletions(-) Applied to target-pending/for-next, with the extra incremental patch for a common target_ua_alloc_lun() caller. Btw, very happy to see REPORTED_LUNS_DATA_HAS_CHANGED support include for v4.2-rc1 code. 8-) Thanks Hannes! --nab -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] target: Update UA handling
On Wed, 2015-06-17 at 08:25 +0200, Hannes Reinecke wrote: On 06/17/2015 08:10 AM, Nicholas A. Bellinger wrote: On Thu, 2015-06-11 at 10:01 +0200, Hannes Reinecke wrote: Hi Nic, lio-target is very minimalistic when it comes to generate UAs; primarily they are generated for persistent reservations, but generic changes tend to be ignored. This patchset updates the UA handling and generates UA for internal state changes (REPORTED LUNS DATA CHANGED, INQUIRY DATA CHANGED, and LUN RESET OCCURRED). Funnily enough this triggers some issues with the SCSI stack; I'll be sending out patches for that, too. Hannes Reinecke (6): target_core_alua: Correct UA handling when switching states target: Remove 'ua_nacl' pointer from se_ua structure target: use 'se_dev_entry' when allocating UAs target: Send UA on ALUA target port group change target: Send UA upon LUN RESET tmr completion target: Send UA when changing LUN inventory drivers/target/target_core_alua.c | 56 +- drivers/target/target_core_device.c| 26 +++- drivers/target/target_core_pr.c| 31 +++ drivers/target/target_core_transport.c | 29 ++ drivers/target/target_core_ua.c| 24 ++- drivers/target/target_core_ua.h| 5 ++- include/target/target_core_base.h | 1 - 7 files changed, 121 insertions(+), 51 deletions(-) Applied to target-pending/for-next, with the extra incremental patch for a common target_ua_alloc_lun() caller. Btw, very happy to see REPORTED_LUNS_DATA_HAS_CHANGED support include for v4.2-rc1 code. 8-) Yeah; I needed a quick testbed for my ALUA update, and thought that tcm_loop would fit the bill. As it turned out, not quite. Hence the patches. BTW: the main issue I have with current lio-target is that you can only configure it _after_ the target has been enabled. IE if you want to add another ALUA state you have to create another TPG, and set this to the required ALUA state. But you can modify the TPG allegiance only _after_ the LUN has been created and is visible to the host. Which means that the initiator inevitably sees both states, and it's impossible to have the LUN start off with a different than the default ALUA state. (This is especially important if one would want to test the READ CAPACITY support in ALUA standby state). Would you be okay with changing that? Sounds like a reasonable case to support. No objections to allowing default ALUA access state to be changed, ahead of actual se_device configfs symlink to fabric se_lun export. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] target: Update UA handling
On 06/17/2015 08:10 AM, Nicholas A. Bellinger wrote: On Thu, 2015-06-11 at 10:01 +0200, Hannes Reinecke wrote: Hi Nic, lio-target is very minimalistic when it comes to generate UAs; primarily they are generated for persistent reservations, but generic changes tend to be ignored. This patchset updates the UA handling and generates UA for internal state changes (REPORTED LUNS DATA CHANGED, INQUIRY DATA CHANGED, and LUN RESET OCCURRED). Funnily enough this triggers some issues with the SCSI stack; I'll be sending out patches for that, too. Hannes Reinecke (6): target_core_alua: Correct UA handling when switching states target: Remove 'ua_nacl' pointer from se_ua structure target: use 'se_dev_entry' when allocating UAs target: Send UA on ALUA target port group change target: Send UA upon LUN RESET tmr completion target: Send UA when changing LUN inventory drivers/target/target_core_alua.c | 56 +- drivers/target/target_core_device.c| 26 +++- drivers/target/target_core_pr.c| 31 +++ drivers/target/target_core_transport.c | 29 ++ drivers/target/target_core_ua.c| 24 ++- drivers/target/target_core_ua.h| 5 ++- include/target/target_core_base.h | 1 - 7 files changed, 121 insertions(+), 51 deletions(-) Applied to target-pending/for-next, with the extra incremental patch for a common target_ua_alloc_lun() caller. Btw, very happy to see REPORTED_LUNS_DATA_HAS_CHANGED support include for v4.2-rc1 code. 8-) Yeah; I needed a quick testbed for my ALUA update, and thought that tcm_loop would fit the bill. As it turned out, not quite. Hence the patches. BTW: the main issue I have with current lio-target is that you can only configure it _after_ the target has been enabled. IE if you want to add another ALUA state you have to create another TPG, and set this to the required ALUA state. But you can modify the TPG allegiance only _after_ the LUN has been created and is visible to the host. Which means that the initiator inevitably sees both states, and it's impossible to have the LUN start off with a different than the default ALUA state. (This is especially important if one would want to test the READ CAPACITY support in ALUA standby state). Would you be okay with changing that? Cheers, Hannes -- Dr. Hannes ReineckezSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] target: Update UA handling
Hi Nic, lio-target is very minimalistic when it comes to generate UAs; primarily they are generated for persistent reservations, but generic changes tend to be ignored. This patchset updates the UA handling and generates UA for internal state changes (REPORTED LUNS DATA CHANGED, INQUIRY DATA CHANGED, and LUN RESET OCCURRED). Funnily enough this triggers some issues with the SCSI stack; I'll be sending out patches for that, too. Hannes Reinecke (6): target_core_alua: Correct UA handling when switching states target: Remove 'ua_nacl' pointer from se_ua structure target: use 'se_dev_entry' when allocating UAs target: Send UA on ALUA target port group change target: Send UA upon LUN RESET tmr completion target: Send UA when changing LUN inventory drivers/target/target_core_alua.c | 56 +- drivers/target/target_core_device.c| 26 +++- drivers/target/target_core_pr.c| 31 +++ drivers/target/target_core_transport.c | 29 ++ drivers/target/target_core_ua.c| 24 ++- drivers/target/target_core_ua.h| 5 ++- include/target/target_core_base.h | 1 - 7 files changed, 121 insertions(+), 51 deletions(-) -- 1.8.5.2 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
