All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: Uday Shankar <ushankar@purestorage.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, ming.lei@redhat.com
Subject: Re: [PATCH 2/4] ublk: refactor recovery configuration flag helpers
Date: Sun, 30 Jun 2024 21:56:36 +0800	[thread overview]
Message-ID: <ZoFkFB8Fcw5gCDln@fedora> (raw)
In-Reply-To: <Zn2cuwpM+/dK/682@dev-ushankar.dev.purestorage.com>

On Thu, Jun 27, 2024 at 11:09:15AM -0600, Uday Shankar wrote:
> When I say "behavior A + 2," I mean behavior A and behavior 2 at the
> same time on the same ublk device. I still think this is not supported
> with current ublk_drv, see below.
> 
> > > the ublk server can "handle" the I/O error because during this time,
> > > there is no ublk server and all decisions on how to handle I/O are made
> > > by ublk_drv directly (based on configuration flags specified when the
> > > device was created).
> > > 
> > > If the ublk server created the device with UBLK_F_USER_RECOVERY, then
> > > when the ublk server has crashed (and not restarted yet), I/Os issued by
> > > the application will queue/hang until the ublk server comes back and
> > > recovers the device, because the underlying request_queue is left in a
> > > quiesced state. So in this case, behavior A is not possible.
> > 
> > When ublk server is crashed, ublk_abort_requests() will be called to fail
> > queued inflight requests. Meantime ubq->canceling is set to requeue
> > new request instead of forwarding it to ublk server.
> > 
> > So behavior A should be supported easily by failing request in
> > ublk_queue_rq() if ubq->canceling is set.
> 
> This argument only works for devices created without
> UBLK_F_USER_RECOVERY. If UBLK_F_USER_RECOVERY is set, then the
> request_queue for the device is left in a quiesced state and so I/Os
> will not even get to ublk_queue_rq. See the following as proof (using a
> build of ublksrv master):

I meant that the following one-line patch may address your issue:


diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
index 4e159948c912..a89240f4f7b0 100644
--- a/drivers/block/ublk_drv.c
+++ b/drivers/block/ublk_drv.c
@@ -1068,7 +1068,7 @@ static inline void __ublk_abort_rq(struct ublk_queue *ubq,
 		struct request *rq)
 {
 	/* We cannot process this rq so just requeue it. */
-	if (ublk_queue_can_use_recovery(ubq))
+	if (ublk_queue_can_use_recovery_reissue(ubq))
 		blk_mq_requeue_request(rq, false);
 	else
 		blk_mq_end_request(rq, BLK_STS_IOERR);


Thanks, 
Ming


  reply	other threads:[~2024-06-30 13:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-17 19:44 [PATCH 0/4] ublk: support device recovery without I/O queueing Uday Shankar
2024-06-17 19:44 ` [PATCH 1/4] ublk: check recovery flags for validity Uday Shankar
2024-06-18  2:00   ` Ming Lei
2024-07-23 19:32     ` Uday Shankar
2024-06-17 19:44 ` [PATCH 2/4] ublk: refactor recovery configuration flag helpers Uday Shankar
2024-06-18  2:11   ` Ming Lei
2024-06-26 17:22     ` Uday Shankar
2024-06-27  1:17       ` Ming Lei
2024-06-27 17:09         ` Uday Shankar
2024-06-30 13:56           ` Ming Lei [this message]
2024-07-01 21:02             ` Uday Shankar
2024-07-02  4:07               ` Ming Lei
2024-07-02 11:09   ` Ming Lei
2024-09-17  0:26     ` Uday Shankar
2024-06-17 19:44 ` [PATCH 3/4] ublk: merge stop_work and quiesce_work Uday Shankar
2024-07-02 13:31   ` Ming Lei
2024-06-17 19:44 ` [PATCH 4/4] ublk: support device recovery without I/O queueing Uday Shankar
2024-07-02 13:46   ` Ming Lei
2024-09-17  0:29     ` Uday Shankar

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=ZoFkFB8Fcw5gCDln@fedora \
    --to=ming.lei@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    --cc=ushankar@purestorage.com \
    /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.