[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Different type of qcow2_get_cluster_type

From: Eric Blake
Subject: Re: [Qemu-devel] Different type of qcow2_get_cluster_type
Date: Tue, 18 Sep 2018 08:50:34 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

On 9/18/18 3:45 AM, lampahome wrote:

Both values correspond to L2 entries with bit 0 set.  However,
QCOW2_CLUSTER_ZERO_ALLOC is an entry that has a non-zero value in bits 9-55
(the cluster has an allocated host location, we guarantee that things read
as zero regardless of whether the host data actually contains zeroes at
that offset, and writes go directly to that offset with no further
allocation required); while QCOW2_CLUSTER_ZERO_PLAIN is an entry with all
zeros in bits 9-55 (we guarantee things read as zero, but writes have to
allocate a new cluster because we have not reserved any space in the host

If I let one entry called l2_addr of l2 table is 1(also the
to make it as discard.

Rather, marking a cluser as QCOW2_CLUSTER_ZERO_PLAIN makes that cluster have read-as-zero semantics. Another option for discard would be writing 0 to the l2 table to make the cluster defer to the backing file (that is what is done when you use 'qemu-img commit', but not something currently accessible to QMP commands on a live guest).

Note that when there is no backing file, marking a cluster as unallocated (l2 entry of 0) vs. read-as-zero (l2 entry of 1) has identical guest-visible behavior; the only time you can tell the two apart is when there is a backing file. But when there IS a backing file, marking a cluster as defer-to-backing means that reads from that area now revived the contents of the disk from the backing file. Although read-after-discard is undefined (guests should NOT be relying on any specific data to be present after a discard - after all it is advisory), the two most common behaviors of discard are 1) no-op (you read what was there before the discard) 2) read zeros (you get a stable read). Marking a cluster as read-as-zero achieves option 2, but marking it as unallocated defer-to-backing would be a third behavior, 3) read stale data from some previous point in time. Since a guest might be trying to use discard to clean up sensitive data (even though such an attempt is not guaranteed to work, since discard is advisory), it is safer to avoid behavior 3 as it potentially leaks data to the guest that it previously thought was indeed discarded.

After I run qemu-img commit image, and the l2_addr also commit to its
backing file.

But I saw the same entry l2_addr of l2 table in backing file doesn't show
1, and write corresponding cluster with zero.

Is that normal?

It is normal for committing a read-as-zero cluster to a backing image to cause the backing image to also read as zeros. Whether it is done by actually wiping out the cluster in the backing file, or by merely setting the read-as-zero bit on the l2 entry but otherwise leaving the cluster allocated, is an implementation detail that shouldn't affect guest behavior (but may need a tuning knob to affect host allocation behavior, so that you can choose between keeping an image fully allocated, vs. aggressively trying to keep the image sparse). You are welcome to try and submit patches to add such knobs.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]