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

Re: Preserving transactions accross Xenstored Live-Update

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.


Julien Grall



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.