Re: [PATCH 0/4] scsi: remove devices in ALUA transitioning status

Ewan D. Milne
2020-11-07T00:03:18Z

On Wed, 2020-09-30 at 10:02 +0200, Hannes Reinecke wrote:
> Hi all,
>
> during testing we found that there is an issue with dev_loss_tmo and
> devices in ALUA transitioning state.
> What happens is that I/O gets requeued via BLK_STS_RESOURCE for these
> devices, so when dev_loss_tmo triggers the SCSI core cannot flush the
> request list as I/O is simply requeued.
>
> So when the driver is trying to re-establish the device it'll wait
> for
> that last reference to drop in order to re-attach the device, but as
> I/O
> is still outstanding on the (old) device it'll wait for ever.
>
> Fix this by returning 'BLK_STS_AGAIN' from scsi_dh_alua when the
> device
> is in ALUA transitioning, and also set the 'transitioning' state when
> scsi_dh_alua is receiving a sense code, and not only after
> scsi_dh_alua
> successfully received the response to a REPORT TARGET PORT GROUPS
> command.
>
> Hannes Reinecke (4):
> block: return status code in blk_mq_end_request()
> scsi_dh_alua: return BLK_STS_AGAIN for ALUA transitioning state
> scsi_dh_alua: set 'transitioning' state on unit attention
> scsi: return BLK_STS_AGAIN for ALUA transitioning
>
> block/blk-mq.c | 2 +-
> drivers/scsi/device_handler/scsi_dh_alua.c | 10 +++++++++-
> drivers/scsi/scsi_lib.c | 8 ++++++++
> 3 files changed, 18 insertions(+), 2 deletions(-)
>

We had a report of I/O hangs during storage controller resets
and analysis of the kernel state showed the sdev in ALUA transitioning.

The patch set fixes the ALUA transitioning issue, it looks good.
There was a reproducible test case.

Reviewed-by: Ewan D. Milne <emilne@redhat.com>

-Ewan