Re: [Xen-devel] /proc/xen/xenbus supports watch?

[Andrew Warfield <andrew.warfield@xxxxxxxxxxxx>]

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