On 10/11/2010 05:49 PM, Anthony Liguori wrote:
On 10/11/2010 09:58 AM, Avi Kivity wrote:
A leak is unacceptable. It means an image can grow to an unbounded
size. If you are a server provider offering multitenancy, then a
malicious guest can potentially grow the image beyond it's allotted
size causing a Denial of Service attack against another tenant.
This particular leak cannot grow, and is not controlled by the guest.
As the image gets moved from hypervisor to hypervisor, it can keep
growing if given a chance to fill up the disk, then trim it all way.
In a mixed hypervisor environment, it just becomes a numbers game.
I don't see how it can grow. Both the freelist and the clusters it
points to consume space, which becomes a leak once you move it to a
hypervisor that doesn't understand the freelist. The older hypervisor
then allocates new blocks. As soon as it performs a metadata scan (if
ever), the freelist is reclaimed.
You could only get a growing leak if you moved it to a hypervisor that
doesn't perform metadata scans, but then that is independent of the
freelist.
A freelist has to be a non-optional feature. When the freelist bit
is set, an older QEMU cannot read the image. If the freelist is
completed used, the freelist bit can be cleared and the image is
then usable by older QEMUs.
Once we support TRIM (or detect zeros) we'll never have a clean
freelist.
Zero detection doesn't add to the free list.
Why not? If a cluster is zero filled, you may drop it (assuming no
backing image).
A potential solution here is to treat TRIM a little differently than
we've been discussing.
When TRIM happens, don't immediately write an unallocated cluster
entry for the L2. Leave the L2 entry in-tact. Don't actually write a
UCE to the L2 until you actually allocate the block.
This implies a cost because you'll need to do metadata syncs to make
this work. However, that eliminates leakage.
The information is lost on shutdown; and you can have a large number of
unallocated-in-waiting clusters (like a TRIM issued by mkfs, or a user
expecting a visit from RIAA).
A slight twist on your proposal is to have an allocated-but-may-drop bit
in a L2 entry. TRIM or zero detection sets the bit (leaving the cluster
number intact). A following write to the cluster needs to clear the
bit; if we reallocate the cluster we need to replace it with a ZCE.
This makes the freelist all L2 entries with the bit set; it may be less
efficient than a custom data structure though.
--
error compiling committee.c: too many arguments to function