public inbox for linux-nvme@lists.infradead.org
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>,
	linux-nvme@lists.infradead.org, Keith Busch <kbusch@kernel.org>,
	Johannes Thumshirn <johannes.thumshirn@wdc.com>
Subject: Re: [PATCH] nvme: zns: limit max_zone_append by max_segments
Date: Mon, 31 Jul 2023 23:12:43 +0900	[thread overview]
Message-ID: <8da417c3-f505-ebfc-c92a-509fee68cfa3@kernel.org> (raw)
In-Reply-To: <ZMfAA0yDhgvekjb4@infradead.org>

On 7/31/23 23:06, Christoph Hellwig wrote:
> On Mon, Jul 31, 2023 at 11:01:21PM +0900, Damien Le Moal wrote:
>> We cannot do that in zonefs because there is no metadata to handle a possible
>> reordering of the fragments of a split large zone append. Hence zonefs limits
>> writes size to max zone append on entry and never tries to do larger writes. But
>> the ZNS limit bug resulted in the split. At least for zonefs, I think there is
>> no need to use the special bio add page since with a proper limit, we should
>> never see a split.
> 
> Then we need to bring back something like the code removed in
> 8e81aa16a42169faae1ba15cd648cc8bb83eaa48, although I'd kinda hate that,
> and I don't really say how that would protect against reordering either.

For zonefs, their is never any reordering because their is no split, as long as
max zone append sectors limit indicates the maximum size of a zone append BIO
that can be built without ever needing splitting.

So if we fix the zns limit, zonefs does not really need a fix, eventhough the
code would be a little weird as-is.

-- 
Damien Le Moal
Western Digital Research



  reply	other threads:[~2023-07-31 14:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-31 11:46 [PATCH] nvme: zns: limit max_zone_append by max_segments Shin'ichiro Kawasaki
2023-07-31 12:03 ` Damien Le Moal
2023-07-31 13:51   ` Christoph Hellwig
2023-07-31 14:01     ` Damien Le Moal
2023-07-31 14:06       ` Christoph Hellwig
2023-07-31 14:12         ` Damien Le Moal [this message]
2023-07-31 14:26           ` Christoph Hellwig
2023-07-31 14:33             ` Damien Le Moal
2023-07-31 13:46 ` Christoph Hellwig
2023-07-31 14:02   ` Damien Le Moal
2023-07-31 14:05     ` Christoph Hellwig
2023-07-31 14:07       ` Damien Le Moal
2023-07-31 14:08         ` Christoph Hellwig

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=8da417c3-f505-ebfc-c92a-509fee68cfa3@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=hch@infradead.org \
    --cc=johannes.thumshirn@wdc.com \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=shinichiro.kawasaki@wdc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox