Re: Preserving transactions accross Xenstored Live-Update

[Julien Grall <julien@xxxxxxx>]

On 19/05/2021 13:32, Julien Grall wrote:
> 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.
I meant "foo" here. Sorry for the confusion.

> 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