All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Bunker <brian@purestorage.com>
To: linux-scsi@vger.kernel.org, Hannes Reinecke <hare@suse.de>
Subject: [PATCH 1/1] scsi_dh_alua: properly handling the ALUA transitioning state
Date: Mon, 2 May 2022 08:09:17 -0700	[thread overview]
Message-ID: <CAHZQxy+4sTPz9+pY3=7VJH+CLUJsDct81KtnR2be8ycN5mhqTg@mail.gmail.com> (raw)

The handling of the ALUA transitioning state is currently broken. When
a target goes into this state, it is expected that the target is
allowed to stay in this state for the implicit transition timeout
without a path failure. The handler has this logic, but it gets
skipped currently.

When the target transitions, there is in-flight I/O from the
initiator. The first of these responses from the target will be a unit
attention letting the initiator know that the ALUA state has changed.
The remaining in-flight I/Os, before the initiator finds out that the
portal state has changed, will return not ready, ALUA state is
transitioning. The portal state will change to
SCSI_ACCESS_STATE_TRANSITIONING. This will lead to all new I/O
immediately failing the path unexpectedly. The path failure happens in
less than a second instead of the expected successes until the
transition timer is exceeded.

This change allows I/Os to continue while the path is in the ALUA
transitioning state. The handler already takes care of a target that
stays in the transitioning state for too long by changing the state to
ALUA state standby once the transition timeout is exceeded at which
point the path will fail.

Signed-off-by: Brian Bunker <brian@purestorage.com>
Acked-by: Krishna Kant <krishna.kant@purestorage.com>
Acked-by: Seamus Connor <sconnor@purestorage.com>
___
diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c
b/drivers/scsi/device_handler/scsi_dh_alua.c
index 37d06f993b76..1d9be771f3ee 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -1172,9 +1172,8 @@ static blk_status_t alua_prep_fn(struct
scsi_device *sdev, struct request *req)
        case SCSI_ACCESS_STATE_OPTIMAL:
        case SCSI_ACCESS_STATE_ACTIVE:
        case SCSI_ACCESS_STATE_LBA:
-               return BLK_STS_OK;
        case SCSI_ACCESS_STATE_TRANSITIONING:
-               return BLK_STS_AGAIN;
+               return BLK_STS_OK;
        default:
                req->rq_flags |= RQF_QUIET;
                return BLK_STS_IOERR;
-- 
Brian Bunker
PURE Storage, Inc.
brian@purestorage.com

             reply	other threads:[~2022-05-02 15:09 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-02 15:09 Brian Bunker [this message]
2022-05-02 16:22 ` [PATCH 1/1] scsi_dh_alua: properly handling the ALUA transitioning state Hannes Reinecke
2022-05-03  0:50 ` Martin K. Petersen
2022-05-20 10:57   ` Martin Wilck
2022-05-20 12:06     ` Hannes Reinecke
2022-05-20 14:03       ` Martin Wilck
2022-05-20 19:08         ` Mike Christie
2022-05-20 20:03           ` Martin Wilck
2022-05-21  2:52             ` Brian Bunker
2022-05-23 16:03               ` Martin Wilck
2022-05-23 16:52                 ` Brian Bunker
2022-05-24  8:29                   ` Martin Wilck
2022-05-21 10:17             ` Hannes Reinecke
2022-05-23 15:33               ` Martin Wilck
2022-05-21 16:58             ` Mike Christie
2022-05-24  5:25 ` Christoph Hellwig
2022-05-24  5:33   ` Hannes Reinecke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHZQxy+4sTPz9+pY3=7VJH+CLUJsDct81KtnR2be8ycN5mhqTg@mail.gmail.com' \
    --to=brian@purestorage.com \
    --cc=hare@suse.de \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.