From: Klaus Jensen <its@irrelevant.dk>
To: Dmitry Fomichev <Dmitry.Fomichev@wdc.com>
Cc: Fam Zheng <fam@euphon.net>, Kevin Wolf <kwolf@redhat.com>,
"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
Klaus Jensen <k.jensen@samsung.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Max Reitz <mreitz@redhat.com>, Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH 00/16] hw/block/nvme: zoned namespace command set
Date: Fri, 25 Sep 2020 19:27:15 +0200 [thread overview]
Message-ID: <20200925172715.GA1931129@apples.localdomain> (raw)
In-Reply-To: <MN2PR04MB5951D128DA6A5C9F6101C707E1360@MN2PR04MB5951.namprd04.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1678 bytes --]
On Sep 25 17:06, Dmitry Fomichev wrote:
> > From: Klaus Jensen <k.jensen@samsung.com>
> >
> > * Standard blockdev-based approach to persistent state. The
> >
> > implementation uses a plain blockdev associated with the nvme-ns
> >
> > device for storing state persistently. This same 'pstate' blockdev
> >
> > is also used for logical block allocation tracking.
> >
>
> Is persistent state mandatory or optional? Sorry for asking, but I am
> still catching up with your other patches. I think having it optional is
> a big benefit for performance testing.
>
Yes, the 'pstate' blockdev is optional.
> >
> >
> > * Relies on automatic configuration of DLFEAT according to what the
> >
> > underlying blockdev provides (i.e. BDRV_O_UNMAP for guaranteeing
> >
> > zeroes on discarded blocks) for handling reads in the gaps between
> >
> > write pointer, ZCAP and ZSZE. Issues discards for zone resets. This
> >
> > removes the zero filling.
> >
>
> Doesn't this make non-zero fill patterns impossible? In many storage
> environments, vendors and admins are adamant about having varying
> fill patterns to see who caused the data corruption if there is one.
> Not sure how important this for the particular application, but WDC
> series provides the functionality to specify the fill pattern.
>
That *is* a good point.
By default I think it should default to either the 0x00 fill pattern (if
supported by the underlying blockdev), or "no fill pattern reported"
when 0x00's cannot be guaranteed. But, an option to enable filling with,
say 0xff, like you do in your series, would be nice.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2020-09-25 17:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 20:45 [PATCH 00/16] hw/block/nvme: zoned namespace command set Klaus Jensen
2020-09-24 20:45 ` [PATCH 01/16] hw/block/nvme: add nsid to get/setfeat trace events Klaus Jensen
2020-09-24 20:45 ` [PATCH 02/16] hw/block/nvme: add trace event for requests with non-zero status code Klaus Jensen
2020-09-24 20:45 ` [PATCH 03/16] hw/block/nvme: make lba data size configurable Klaus Jensen
2020-09-24 21:13 ` Klaus Jensen
2020-09-24 20:45 ` [PATCH 04/16] hw/block/nvme: reject io commands if only admin command set selected Klaus Jensen
2020-09-24 20:45 ` [PATCH 05/16] hw/block/nvme: consolidate read, write and write zeroes Klaus Jensen
2020-09-24 20:45 ` [PATCH 06/16] hw/block/nvme: add support for dulbe and block utilization tracking Klaus Jensen
2020-09-24 20:45 ` [PATCH 07/16] hw/block/nvme: add commands supported and effects log page Klaus Jensen
2020-09-24 20:45 ` [PATCH 08/16] hw/block/nvme: support namespace types Klaus Jensen
2020-09-24 20:45 ` [PATCH 09/16] hw/block/nvme: add basic read/write for zoned namespaces Klaus Jensen
2020-09-24 20:45 ` [PATCH 10/16] hw/block/nvme: add the zone management receive command Klaus Jensen
2020-09-24 20:45 ` [PATCH 11/16] hw/block/nvme: add the zone management send command Klaus Jensen
2020-09-24 20:45 ` [PATCH 12/16] hw/block/nvme: add the zone append command Klaus Jensen
2020-09-24 20:45 ` [PATCH 13/16] hw/block/nvme: track and enforce zone resources Klaus Jensen
2020-09-24 20:45 ` [PATCH 14/16] hw/block/nvme: allow open to close transitions by controller Klaus Jensen
2020-09-24 20:45 ` [PATCH 15/16] hw/block/nvme: support zone active excursions Klaus Jensen
2020-09-24 20:45 ` [PATCH 16/16] hw/block/nvme: support reset/finish recommended limits Klaus Jensen
2020-09-24 22:43 ` [PATCH 00/16] hw/block/nvme: zoned namespace command set no-reply
2020-09-25 7:55 ` Klaus Jensen
2020-09-25 1:24 ` Keith Busch
2020-09-25 5:27 ` Klaus Jensen
2020-09-25 17:06 ` Dmitry Fomichev
2020-09-25 17:27 ` Klaus Jensen [this message]
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=20200925172715.GA1931129@apples.localdomain \
--to=its@irrelevant.dk \
--cc=Dmitry.Fomichev@wdc.com \
--cc=fam@euphon.net \
--cc=k.jensen@samsung.com \
--cc=kbusch@kernel.org \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).