qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: Markus Armbruster <armbru@redhat.com>, Sam Li <faithilikerun@gmail.com>
Cc: qemu-devel@nongnu.org, Hanna Reitz <hreitz@redhat.com>,
	dmitry.fomichev@wdc.com, qemu-block@nongnu.org,
	Eric Blake <eblake@redhat.com>,
	hare@suse.de, Kevin Wolf <kwolf@redhat.com>,
	stefanha@redhat.com
Subject: Re: [PATCH v7 2/4] qcow2: add configurations for zoned format extension
Date: Tue, 20 Feb 2024 11:25:36 +0900	[thread overview]
Message-ID: <768197a3-bfdb-4bca-a550-acad6a94c726@kernel.org> (raw)
In-Reply-To: <871q98f94t.fsf@pond.sub.org>

On 2/20/24 06:15, Markus Armbruster wrote:
>>>>> Making this member @size mandatory means we must specify it when
>>>>> BlockdevCreateOptionsQcow2 member @zone is present and @zone's member
>>>>> @mode is "host-managed".  Feels right to me.  Am I missing anything?
>>>>
>>>> That's right. And the checks when creating such an img can help do
>>>> that. It's not specified in the .json file directly.
>>>
>>> What would break if we did specify it in the QAPI schema directly?
>>
>> Nothing I think. We can keep the current schema and add a default zone
>> size like 131072.
> 
> I believe making the member mandatory makes a lot more sense.
> 
> I guess we can keep @capacity and @max-append-bytes keep optional *if*
> we can come up with sensible defaults.

Yes, @capacity can be optional and default to the zone size.  @max-append-bytes
can also be optional and default to the regular read/write max size.

However, defining a "sensible" default for the zone size is rather tricky. The
reason is that zones are generally sized according to the device speed. Zones
are 256MB on HDDs (which takes about 1s to fully write sequentially) while NVMe
ZNS devices will more likely have a zone size of 1-2 GB (because the device is
much faster). If we stick with such approach, a sensible zone size would depend
on how fast the qcow2 image backing is. I.e. 256 MB would be more appropriate
for a qcow2 image on a file stored on HDD while larger sizes may be better for
SSD backed images. But that is also not accounting for the host page caching
which can "show" the qcow2 image as being much faster than its backing storage
really is.

So I would be tempted to say that defaulting to 0 to force the user to specify a
zone size would be safer. But if you really want a non-0 default, then maybe
256MB or so may be OK as that is the most commonly used value out there for
zoned storage (there are literally millions of SMR drives running in production
systems out there and NVMe ZNS devices are not widely used yet).


-- 
Damien Le Moal
Western Digital Research



  reply	other threads:[~2024-02-20  2:26 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-22 18:48 [PATCH v7 0/4] Add full zoned storage emulation to qcow2 driver Sam Li
2024-01-22 18:48 ` [PATCH v7 1/4] docs/qcow2: add the zoned format feature Sam Li
2024-01-22 18:48 ` [PATCH v7 2/4] qcow2: add configurations for zoned format extension Sam Li
2024-02-19 11:57   ` Markus Armbruster
2024-02-19 12:05     ` Markus Armbruster
2024-02-19 12:23       ` Sam Li
2024-02-19 14:39         ` Markus Armbruster
2024-02-19 14:48           ` Sam Li
2024-02-19 15:56             ` Markus Armbruster
2024-02-19 16:09               ` Sam Li
2024-02-19 20:42                 ` Markus Armbruster
2024-02-19 20:46                   ` Sam Li
2024-02-19 21:15                     ` Markus Armbruster
2024-02-20  2:25                       ` Damien Le Moal [this message]
2024-03-12 15:04   ` Stefan Hajnoczi
2024-01-22 18:48 ` [PATCH v7 3/4] qcow2: add zoned emulation capability Sam Li
2024-03-12 18:30   ` Stefan Hajnoczi
2024-09-23 11:06     ` Sam Li
2024-09-23 13:22       ` Damien Le Moal
2024-09-23 13:40         ` Sam Li
2024-09-23 13:48           ` Damien Le Moal
2024-09-23 13:57             ` Sam Li
2024-01-22 18:48 ` [PATCH v7 4/4] iotests: test the zoned format feature for qcow2 file Sam Li

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=768197a3-bfdb-4bca-a550-acad6a94c726@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=armbru@redhat.com \
    --cc=dmitry.fomichev@wdc.com \
    --cc=eblake@redhat.com \
    --cc=faithilikerun@gmail.com \
    --cc=hare@suse.de \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@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 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).