All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Cc: Bart Van Assche <bvanassche@acm.org>,
	Christoph Hellwig <hch@lst.de>, Ming Lei <ming.lei@redhat.com>,
	Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
	Jan Kara <jack@suse.cz>,
	Johannes Thumshirn <johannes.thumshirn@wdc.com>
Subject: Re: [PATCH 2/2] block: Split and submit bios in LBA order
Date: Mon, 27 Mar 2023 01:45:52 +0200	[thread overview]
Message-ID: <20230326234552.GC20017@lst.de> (raw)
In-Reply-To: <5b450fee-714b-224e-69ae-497633e005ed@opensource.wdc.com>

On Sun, Mar 26, 2023 at 10:45:08AM +0900, Damien Le Moal wrote:
> > Although the above sounds interesting to me, I think the following two 
> > scenarios are not handled by the above approach and can lead to reordering:
> > * The SCSI device reporting a unit attention.
> > * The SCSI device responding with the SCSI status "BUSY". The UFS 
> > standard explicitly allows this. From the UFS standard: "If the unit is 
> > not ready to accept a new command (e.g., still processing previous 
> > command) a STATUS response of BUSY will be returned."
> 
> Yes, that likely would be an issue for regular writes, but likely not for zone
> append emulation using regular writes though, since a "busy" return for a ZA
> emulated regular write can be resent later with a different aligned write location.

Exactly.  That's why ZONE_APPEND is the only really viable high-level
interface.

  reply	other threads:[~2023-03-26 23:45 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-17 19:59 [PATCH 0/2] Submit split bios in LBA order Bart Van Assche
2023-03-17 19:59 ` [PATCH 1/2] block: Split blk_recalc_rq_segments() Bart Van Assche
2023-03-18  6:38   ` Christoph Hellwig
2023-03-17 19:59 ` [PATCH 2/2] block: Split and submit bios in LBA order Bart Van Assche
2023-03-17 22:28   ` Jan Kara
2023-03-18  6:33     ` Christoph Hellwig
2023-03-17 23:38   ` Ming Lei
2023-03-17 23:45     ` Bart Van Assche
2023-03-20 23:28       ` Ming Lei
2023-03-20 23:32         ` Bart Van Assche
2023-03-21  0:44           ` Ming Lei
2023-03-21  1:46             ` Damien Le Moal
2023-03-21  2:17               ` Ming Lei
2023-03-21  3:24                 ` Damien Le Moal
2023-03-21  8:00                   ` Ming Lei
2023-03-21  8:51                     ` Damien Le Moal
2023-03-21  9:09                       ` Christoph Hellwig
2023-03-21  9:50                         ` Damien Le Moal
2023-03-21  5:55           ` Christoph Hellwig
2023-03-21 14:36             ` Bart Van Assche
2023-03-23  8:26               ` Christoph Hellwig
2023-03-23 10:28                 ` Damien Le Moal
2023-03-23 16:27                   ` Bart Van Assche
2023-03-23 22:53                     ` Damien Le Moal
2023-03-24 16:55                       ` Bart Van Assche
2023-03-25  2:00                         ` Damien Le Moal
2023-03-25 16:31                           ` Bart Van Assche
2023-03-26  1:45                             ` Damien Le Moal
2023-03-26 23:45                               ` Christoph Hellwig [this message]
2023-03-27 21:06                                 ` Bart Van Assche
2023-03-27 23:43                                   ` Christoph Hellwig
2023-04-06 20:30                                     ` Bart Van Assche
2023-03-27 21:20                               ` Bart Van Assche
2023-03-18  6:42   ` Christoph Hellwig
2023-03-18  6:29 ` [PATCH 0/2] Submit split " Christoph Hellwig
2023-03-20 17:22   ` Bart Van Assche
2023-03-20 21:06     ` Khazhy Kumykov
2023-03-23  8:27     ` Christoph Hellwig
2023-03-24 17:05       ` Bart Van Assche
2023-03-25  2:15         ` Damien Le Moal
2023-03-26 23:42           ` Christoph Hellwig
2023-03-26 23:44         ` Christoph Hellwig
2023-04-06 20:32           ` Bart Van Assche

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=20230326234552.GC20017@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=jack@suse.cz \
    --cc=jaegeuk@kernel.org \
    --cc=johannes.thumshirn@wdc.com \
    --cc=linux-block@vger.kernel.org \
    --cc=ming.lei@redhat.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.