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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
