[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] /proc/xen/xenbus supports watch?
Rusty, Can you explain once again why you think that migrating in-progress transactions is the right thing to do? It seems to me that our transactions are generally pretty small, and I don't imagine them getting problematically bigger in the future. If client-side transaction code is already being written to expect failures and retry when they occur, what is the argument against blowing away in-progress transactions when you migrate. Given that the majority of current transaction code is to do with device drivers and you disconnect/reconnect those on migration anyway, why go through the extra work of adding complexity to migration? a. On 9/22/05, Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote: > On Thu, 2005-09-22 at 10:35 +0100, Keir Fraser wrote: > > Whatever, the client probably needs the code to realise that a bad > > thing has happened and to take appropriate action whichever strategy we > > go for. I suspect they are equivalent complexity for clients. > > I think you've summed it up well. Of these two I'm leaning towards > EAGAIN (which the client can turn into a fake success if they want). > But both are subtle and kinda icky. > > Which is why I am pondering a bundle/unbundle interface for > transactions, so we can migrate them with the domain. Summary: > > 1) Easy to do at the moment: we already snapshot the entire store for > transactions, so we can just bundle/unbundle that. We need > globally-unique transactions IDs, but that's fairly simple. > 2) Each domain adds roughly 5k to the store (this will increase, say > 10k). This means migrating off a node with 100 domains means adding 1M > to the data we have to send *per transaction*. > 3) The store compresses extremely well (~800 bytes per domain), so we > could trivially get it down to 160k/transaction in the 100 domain case. > > You know I treasure simple APIs, and this makes the store API simpler > and so reduces subtle errors in future. > > But is it worth the complexity? > Rusty. > -- > A bad analogy is like a leaky screwdriver -- Richard Braakman > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |