On Thu, 2005-09-22 at 18:01 -0700, Andrew Warfield wrote:
> 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?
Actually, with more thought on your excellent points I've changed my
mind: we should wait for any transactions to complete before saving
domain and sidestep the whole issue.
To recap, the problem is that if we are are halfway through a
transaction when we migrate the domain, it's hard to know what to do on
the next op (eg. "xs_write", "xs_read" etc). Without migrating the
transaction, we can fail the next op with EAGAIN or return "dummy"
values, neither of which is pleasant. (Failing with EAGAIN on commit is
different, and something the caller needs to handle anyway).
Now, we already have this "domain won't save until transactions are
done" simply because we use a single big lock, but this discussion
started because we want to get rid of that lock for /proc/xen/xenbus
(it's fine for drivers). I think we should do so, but keep this
wont-save-during-transactions semantic; it means a waitqueue etc, but I
don't think it's too bad. As you say, our transactions are pretty
small.
Do people like this more?
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home