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
