[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 13:50, Juergen Gross wrote:
On 19.05.21 14:33, Julien Grall wrote:

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

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" inthe 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.

And this is the basic problem, I think.

C Xenstored should be repaired by adding all (remaining) children of a
node into the TID's database when the list of children is modified
either globally or in a transaction. A child having been added globally
needs to be added as "deleted" into the TID's database.

IIUC, for every modifications in the global database, we would need to walk every single transactions and check whether a parent was accessed. Am I correct?

If so, I don't think this is a workable solution because of the cost to execute a single command.

Is it something you plan to address differently with your rework of the DB?


Julien Grall



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