From: Eric Blake <eblake@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
Max Reitz <mreitz@redhat.com>,
Denis Plotnikov <dplotnikov@virtuozzo.com>,
qemu-devel@nongnu.org
Cc: kwolf@redhat.com, den@openvz.org, berto@igalia.com,
armbru@redhat.com, qemu-block@nongnu.org
Subject: Re: [PATCH v22 3/4] qcow2: add zstd cluster compression
Date: Wed, 29 Apr 2020 08:49:43 -0500 [thread overview]
Message-ID: <008d2753-eabd-14a9-22e5-3cb304999051@redhat.com> (raw)
In-Reply-To: <23f0a79a-6e8d-3702-3d82-9db54a442a5f@virtuozzo.com>
On 4/29/20 8:02 AM, Vladimir Sementsov-Ogievskiy wrote:
>>>>> + /*
>>>>> + * The compressed stream from the input buffer may consist of
>>>>> more
>>>>> + * than one zstd frame.
>>>>
>>>> Can it?
>>>
>>> If not, we must require it in the specification.
>>
>> Actually, now that you mention it, it would make sense anyway to add
>> some note to the specification on what exactly compressed with zstd
>> means.
> So, we don't know do we want one frame restriction or not. Do you have a
> preference?
>
I'm a fan of 'be strict in what you produce, liberal in what you
accept'. While our implementation always produces only a single frame of
compressed data, I think our decoder should be prepared to see more than
one frame from other implementations, as that is more liberal than
tightening the specification to require that encoding must produce
exactly one frame.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
next prev parent reply other threads:[~2020-04-29 13:51 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-28 20:00 [PATCH v22 0/4] implement zstd cluster compression method Denis Plotnikov
2020-04-28 20:00 ` [PATCH v22 1/4] qcow2: introduce compression type feature Denis Plotnikov
2020-04-28 20:00 ` [PATCH v22 2/4] qcow2: rework the cluster compression routine Denis Plotnikov
2020-04-28 20:00 ` [PATCH v22 3/4] qcow2: add zstd cluster compression Denis Plotnikov
2020-04-28 21:05 ` Eric Blake
2020-04-29 10:24 ` Max Reitz
2020-04-29 10:37 ` Vladimir Sementsov-Ogievskiy
2020-04-29 12:17 ` Max Reitz
2020-04-29 13:02 ` Vladimir Sementsov-Ogievskiy
2020-04-29 13:49 ` Eric Blake [this message]
2020-04-30 8:26 ` Max Reitz
2020-04-30 9:48 ` Denis Plotnikov
2020-04-30 11:47 ` Max Reitz
2020-04-30 13:56 ` Denis Plotnikov
2020-05-04 7:53 ` Max Reitz
2020-04-29 10:38 ` Denis Plotnikov
2020-04-29 12:24 ` Max Reitz
2020-04-28 20:00 ` [PATCH v22 4/4] iotests: 287: add qcow2 compression type test Denis Plotnikov
2020-04-28 21:08 ` Eric Blake
2020-04-29 10:26 ` Max Reitz
2020-04-29 10:40 ` Denis Plotnikov
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=008d2753-eabd-14a9-22e5-3cb304999051@redhat.com \
--to=eblake@redhat.com \
--cc=armbru@redhat.com \
--cc=berto@igalia.com \
--cc=den@openvz.org \
--cc=dplotnikov@virtuozzo.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.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).