qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 0/6] external backup api


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v2 0/6] external backup api
Date: Mon, 29 Feb 2016 11:22:06 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Markus Armbruster <address@hidden> writes:

[...]
> Consider a QCOW2 image D (for delta) with a backing file B (for base).
> If you open it normally, you see "D over B".  Get LBA Status should
> certainly claim the "deallocated" state only for blocks that are
> allocated neither in D nor B.
>
> However, you can also open D *without* its backing file.  Then you see
> "D over nothing".  Here, get LBA Status should claim "deallocated" state
> for anything not allocated in D.
>
> My proposal is to expose a "just the dirty blocks" view of a block
> backend similarly: it's a *separate* backend that contains *only* the
> dirty blocks.  Attempts to read a clean block behave exactly like
> reading an unmapped block from any other thinly provisioned backend
> (QCOW2 gives you zeroes, if I remember correctly).  I think it's only
> natural to make Get LBA Status claim "deallocated" for exactly the clean
> blocks then.

Regarding implementation: perhaps we can have a "bitmap filter" block
driver that masks out blocks based on a bitmap.  Read-only, at least
until somebody comes up with sane semantics for writing, and a use case
:)

Digression: masking out blocks based on a bitmap is is vaguely similar
to how a COW block driver replaces blocks based on delta.  What makes
such a COW block driver a *format* is persistence.  Same for bitmap
filters.  The question whether we want a bitmap filter *format* is being
discussed elsewhere.  Even if the answer should be "no", we could still
have a non-persistent filter if it's useful.

[...]



reply via email to

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