All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Christoph Hellwig <hch@lst.de>,
	Damien Le Moal <damien.lemoal@opensource.wdc.com>,
	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: Tue, 28 Mar 2023 01:43:11 +0200	[thread overview]
Message-ID: <20230327234311.GA19281@lst.de> (raw)
In-Reply-To: <7b668546-addb-9a47-b6f0-4f2422617ead@acm.org>

On Mon, Mar 27, 2023 at 02:06:09PM -0700, Bart Van Assche wrote:
> Using REQ_OP_ZONE_APPEND may lead to reordering - data being written on the 
> storage medium in another order than the order in which the 
> REQ_OP_ZONE_APPEND commands were submitted.

Only if that reordering actually happens.  Which we're very good at avoiding.
e.g. when looking at btrfs on ZNS drives we see that this reordering does
not actually happen to a quantifiable amount.

> Hence, the number of extents 
> for large files increases and performance when reading large files reduces. 
> To me comparing the performance of these two approaches sounds like a good 
> topic for a research paper. I'm not sure that REQ_OP_ZONE_APPEND is better 
> for all zoned storage workloads than REQ_OP_WRITE.

For REQ_OP_WRITE you absolutely must avoid reordering, so you need to
globally serialize.  If you can come up with a workload where your write
based approach is fast, please show it!

  reply	other threads:[~2023-03-27 23:43 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
2023-03-27 21:06                                 ` Bart Van Assche
2023-03-27 23:43                                   ` Christoph Hellwig [this message]
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=20230327234311.GA19281@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.