qemu-block
[Top][All Lists]
Advanced

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

Re: qcow2 preallocation and backing files


From: Kevin Wolf
Subject: Re: qcow2 preallocation and backing files
Date: Wed, 20 Nov 2019 17:46:26 +0100
User-agent: Mutt/1.12.1 (2019-06-15)

Am 20.11.2019 um 16:58 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 20.11.2019 18:18, Alberto Garcia wrote:
> > On Wed 20 Nov 2019 01:27:53 PM CET, Vladimir Semeeausntsov-Ogievskiy wrote:
> > 
> >> 3. Also, the latter way is inconsistent with discard. Discarded
> >> regions returns zeroes, not clusters from backing. I think discard and
> >> truncate should behave in the same safe zero way.
> > 
> > But then PREALLOC_MODE_OFF implies that the L2 metadata should be
> > preallocated (all clusters should be QCOW2_CLUSTER_ZERO_PLAIN), at least
> > when there is a backing file.
> > 
> > Or maybe we just forbid PREALLOC_MODE_OFF during resize if there is a
> > backing file ?
> > 
> 
> Kevin proposed a fix that alters PREALLOC_MODE_OFF behavior if there is
> a backing file, to allocate L2 metadata with ZERO clusters..
> 
> I don't think that it's the best thing to do, but it's already done,
> it works and seems appropriate for rc3..
> 
> I see now, that change PREALLOC_MODE_OFF behavior may break things,
> first of all qemu-img create, which creating UNALLOCATED qcow2 by
> default for years.

And it still does, because the backing file is added only after giving
the qcow2 image the right size.

But you're right, this is more accidental than by design. I wonder if
there are other problematic cases (and whether merging something like
this in -rc3 isn't rather risky).

> Still, I think that it would be safer to always ZERO expanded part of
> qcow2, regardless of backing file..
> 
> We may add PREALLOC_MODE_ZERO, and use it in mirror, commit, and some
> other calls to bdrv_truncate, except for qcow2 image creation of
> course.

What do we do with image formats that don't support zero clusters and
therefore can't provide PREALLOC_MODE_ZERO? Will commit just fail for
them?

> Then, to improve this mode handling in qcow2, to not allocate all L2
> tables, we may add "zero" bit to L1 table entry.

This would be an incompatible image format change that needs to be
explicitly enabled by the user. This might limit its usefulness a bit.

Kevin




reply via email to

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