From: Kevin Wolf <kwolf@redhat.com>
To: Hanna Reitz <hreitz@redhat.com>
Cc: andrey.shinkevich@virtuozzo.com, eblake@redhat.com,
"Richard W.M. Jones" <rjones@redhat.com>,
qemu-block@nongnu.org, qemu-devel@nongnu.org
Subject: Re: Block alignment of qcow2 compress driver
Date: Fri, 28 Jan 2022 14:19:44 +0100 [thread overview]
Message-ID: <YfPtcGQGIZP4cYrJ@redhat.com> (raw)
In-Reply-To: <54f3a548-ebea-9ed5-6387-5dda2bf92c4e@redhat.com>
Am 28.01.2022 um 13:30 hat Hanna Reitz geschrieben:
> > > I just changed that line of code [2], as shown in [4]. I suppose
> > > the better thing to do would be to have an option for the NBD server
> > > to force-change the announced request alignment, because it can
> > > expect the qemu block layer code to auto-align requests through
> > > RMW. Doing it in the client is wrong, because the NBD server might
> > > want to detect that the client sends unaligned requests and reject
> > > them (though ours doesn’t, it just traces such events[5] – note that
> > > it’s explicitly noted there that qemu will auto-align requests).
> > I know I said I didn't care about performance (in this case), but is
> > there in fact a penalty to sending unaligned requests to the qcow2
> > layer? Or perhaps it cannot compress them?
>
> In qcow2, only the whole cluster can be compressed, so writing compressed
> data means having to write the whole cluster. qcow2 could implement the
> padding by itself, but we decided to just leave the burden of only writing
> full clusters (with the COMPRESSED write flag) on the callers.
>
> Things like qemu-img convert and blockdev-backup just adhere to that by
> design; and the compress driver makes sure to set its request alignment
> accordingly so that requests to it will always be aligned to the cluster
> size (either by its user, or by the qemu block layer which performs the
> padding automatically).
I thought the more limiting factor would be that after auto-aligning the
first request by padding with zeros, the second request to the same
cluster would fail because compression doesn't allow using an already
allocated cluster:
/* Compression can't overwrite anything. Fail if the cluster was already
* allocated. */
cluster_offset = get_l2_entry(s, l2_slice, l2_index);
if (cluster_offset & L2E_OFFSET_MASK) {
qcow2_cache_put(s->l2_table_cache, (void **) &l2_slice);
return -EIO;
}
Did you always just test a single request or why don't you run into
this?
I guess checking L2E_OFFSET_MASK is strictly speaking wrong because it's
invalid for compressed clusters (qcow2_get_cluster_type() feels more
appropriate), but in practice, you will always have non-zero data there,
so it should error out here.
Kevin
next prev parent reply other threads:[~2022-01-28 13:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-28 11:07 Block alignment of qcow2 compress driver Richard W.M. Jones
2022-01-28 11:39 ` Hanna Reitz
2022-01-28 11:48 ` Richard W.M. Jones
2022-01-28 11:57 ` Hanna Reitz
2022-01-28 12:18 ` Richard W.M. Jones
2022-01-28 12:30 ` Hanna Reitz
2022-01-28 13:19 ` Kevin Wolf [this message]
2022-01-28 13:36 ` Richard W.M. Jones
2022-01-28 13:30 ` Richard W.M. Jones
2022-01-28 13:37 ` Richard W.M. Jones
2022-01-28 21:22 ` Eric Blake
2022-01-28 11:56 ` Richard W.M. Jones
2022-01-28 21:40 ` Eric Blake
2022-02-01 14:13 ` Vladimir Sementsov-Ogievskiy
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=YfPtcGQGIZP4cYrJ@redhat.com \
--to=kwolf@redhat.com \
--cc=andrey.shinkevich@virtuozzo.com \
--cc=eblake@redhat.com \
--cc=hreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=rjones@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 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.