All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <Niklas.Cassel@wdc.com>
To: Klaus Jensen <k.jensen@samsung.com>,
	Keith Busch <kbusch@kernel.org>,
	Dmitry Fomichev <Dmitry.Fomichev@wdc.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>
Subject: NVMe ZNS zone append past zone size?
Date: Tue, 19 Jan 2021 10:38:50 +0000	[thread overview]
Message-ID: <20210119103848.GA92347@localhost.localdomain> (raw)

Hello all,


When testing with the ZNS code that is in nvme-next,
I can zone append, targeting the first zone by specifying zslba 0,
and then just put that call it in a while loop, it will
manage to fill up not just zone0, but the whole drive.

Since zslba is defined as:
"Zone Start Logical Block Address (ZSLBA): This field indicates the 64-bit
address of the lowest logical block of the zone in which the data and
metadata, if applicable, associated with this command is to be stored."

Should an append that specifies zslba 0 (== zone 0), be allowed
to write into zone 1 (and beyond).

According to 2.3.1.1 "Writing in Sequential Write Required Zones",
we should get either a "Zone Boundary Error" or "Zone Is Full" error,
depending on zone 0 write pointer, combined with how many LBAs we try
to append.


Looking at the code, I think that this has to be handled in
either nvme_check_zone_write() or nvme_advance_zone_wp().

Considering that Dmitry and Klaus were discussing when to advance
the write pointer, etc, for several of the patch series revisions,
I think it is better to leave a potential fix to you guys.


Kind regards,
Niklas

             reply	other threads:[~2021-01-19 10:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-19 10:38 Niklas Cassel [this message]
2021-01-19 11:19 ` NVMe ZNS zone append past zone size? Klaus Jensen

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=20210119103848.GA92347@localhost.localdomain \
    --to=niklas.cassel@wdc.com \
    --cc=Dmitry.Fomichev@wdc.com \
    --cc=k.jensen@samsung.com \
    --cc=kbusch@kernel.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.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.