[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [PATCH v3 1/2] block: sync bdrv_co_get_blo
From: |
Kashyap Chamarthy |
Subject: |
Re: [Qemu-block] [Qemu-devel] [PATCH v3 1/2] block: sync bdrv_co_get_block_status_above() with bdrv_is_allocated_above() |
Date: |
Mon, 26 Sep 2016 23:42:55 +0200 |
User-agent: |
Mutt/1.6.0.1 (2016-04-01) |
On Mon, Sep 26, 2016 at 05:04:21PM +0200, Kevin Wolf wrote:
> Am 19.09.2016 um 22:39 hat Eric Blake geschrieben:
[...]
> > I typically write this as:
> >
> > L2 <- L1 <- L0
> >
> > (read "L2 backs L1, which in turn backs L0") with the active on the
> > right. So I understand the confusion in Fam's question where you were
> > using the opposite direction.
>
> And I tend to use this one:
>
> base <- sn1 <- sn2 <- top
>
> "sn*" isn't any better than "L*", but having at least one of "base" and
> "top" (or "active") in there disambiguates the roles of the nodes.
Not to quibble over terminology too much, but now that I'm writing a doc
that I want to submit upstream, I began with your (Kevin's) notation.
Then, I thought: Hmm, "sn1" could also be referred to as 'base', and
"sn2" as 'top' when using `block-commit`' (and `block-stream`, once it
starts supporting intermediate streaming?).
And, moreover, as Eric (correctly) warns elsewhere about file-names vs.
points-in-time: the guest state when 'sn1' was created is contained in
'base', so one could argue that 'sn1' ("snapshot 1") is a misnomer, and
is technically 'overlay1'.
So, I used the below notation until recently, including 'active'
(with the rationale Kevin mentioned):
base <- overlay1 <- overlay2 <- active
Then, someone asked: "In the above chain, are you pointing to 'overlay2'
as active, or is 'active' a separate image unto itself"? "Sigh, so it
is still prone to misunderstanding", I thought.
Given that, for now, though slightly more verbose and space-occupying, I
settled on the below (occasionally doing s/base/orig/, to avoid the
"overlay1 could be referred to as 'base' in some cases" problem):
Live QEMU
|
v
base <- overlay1 <- overlay2 <- overlay3
FWIW, the above also avoids the problem of a file called 'active' being
described as: "previously-active, but not anymore, because its contents
are merged into its backing file" in the event of a 'block-commit'.
</end quibble>
--
/kashyap
Re: [Qemu-block] [PATCH v3 1/2] block: sync bdrv_co_get_block_status_above() with bdrv_is_allocated_above(), Max Reitz, 2016/09/19
[Qemu-block] [PATCH v3 2/2] mirror: fix improperly filled copy_bitmap for mirror block job, Denis V. Lunev, 2016/09/15