Currently xenstored does not account domain->nbentry when a transaction
is aborted (either intentionally or via EAGAIN). We hit this case when
adding a lot of disks to a domU: the limit is reached much earlier than
expected, as a number of clashing transactions cause incorrect inflation
of the value of ->nbentry.
There''s been a little discussion internally on the nicest way to fix
this. My current suggestion is along the lines of:
domain_entry_inc()
d = domain to inc as before
if (transaction)
transaction->domain_nbcount[d]++
else
d->nbcount++
(same for _dec)
then in transaction end:
for d in transaction->domains
d->nbcount += transaction->domain_nbcount[d]
But I thought it wise to ask if somebody has a different suggestion, or
preference, before we cook up a patch.
cheers
john
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On 23/5/07 03:46, "John Levon" <levon@movementarian.org> wrote:> Currently xenstored does not account domain->nbentry when a transaction > is aborted (either intentionally or via EAGAIN). We hit this case when > adding a lot of disks to a domU: the limit is reached much earlier than > expected, as a number of clashing transactions cause incorrect inflation > of the value of ->nbentry. > > There''s been a little discussion internally on the nicest way to fix > this. My current suggestion is along the lines of:The principle is clearly right, but domain_nbcount[] isn''t a great idea since the domain-id space is 16 bits (even though we do tend to pack domain ids near zero where possible). Can we dynamically allocate the transaction counts, or assign guaranteed packed identifiers, or store the counts within the tdb file, or something like that? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, May 23, 2007 at 09:20:59AM +0100, Keir Fraser wrote:> > Currently xenstored does not account domain->nbentry when a transaction > > is aborted (either intentionally or via EAGAIN). We hit this case when > > adding a lot of disks to a domU: the limit is reached much earlier than > > expected, as a number of clashing transactions cause incorrect inflation > > of the value of ->nbentry. > > > > There''s been a little discussion internally on the nicest way to fix > > this. My current suggestion is along the lines of: > > The principle is clearly right, but domain_nbcount[] isn''t a great ideaThat was shorthand, we''d keep a list. john _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel