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 Reinecke zSeries & Storage hare@xxxxxxx +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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
