Re: Preserving transactions accross Xenstored Live-Update

[Julien Grall <julien@xxxxxxx>]

Hi Juergen,

On 19/05/2021 10:09, Juergen Gross wrote:
> On 18.05.21 20:11, Julien Grall wrote:
> > I have started to look at preserving transaction accross Live-update in 
> > C Xenstored. So far, I managed to transfer transaction that read/write 
> > existing nodes.
> > Now, I am running into trouble to transfer new/deleted node within a 
> > transaction with the existing migration format.
> > C Xenstored will keep track of nodes accessed during the transaction 
> > but not the children (AFAICT for performance reason).
> Not performance reasons, but because there isn't any need for that:
>
> The children are either unchanged (so the non-transaction node records
> apply), or they will be among the tracked nodes (transaction node
> records apply). So in both cases all children should be known.
In theory, opening a new transaction means you will not see any 
modification in the global database until the transaction has been 
committed. What you describe would break that because a client would be 
able to see new nodes added outside of the transaction.
However, C Xenstored implements neither of the two. Currently, when a 
node is accessed within the transaction, we will also store the names of 
the current children.
To give an example with access to the global DB (prefixed with TID0) and 
within a transaction (TID1)
        1) TID0: MKDIR "data/bar"
        2) Start transaction TID1
        3) TID1: DIRECTORY "data"
                -> This will cache the node data
        4) TID0: MKDIR "data/foo"
                -> This will create "foo" in the global database
        5) TID1: MKDIR "data/fish"
                -> This will create "fish" in the transaction
        5) TID1: DIRECTORY "data"
                -> This will only return "bar" and "fish"

If we Live-Update between 4) and 5). Then we should make sure that "bar" 
cannot be seen in the listing by TID1.
Therefore, I don't think we can restore the children using the global 
node here. Instead we need to find a way to transfer the list of known 
children within the transaction.
As a fun fact, C Xenstored implements weirdly the transaction, so TID1 
will be able to access "bar" if it knows the name but not list it.
> In case a child has been deleted in the transaction, the stream should
> contain a node record for that child with the transaction-id and the
> number of permissions being zero: see docs/designs/xenstore-migration.md
See above why this is not sufficient.

Cheers,

--
Julien Grall