[Xen-bugs] [Bug 487] No space left on device, while writing /local/domain/0/backend/vbd/113/2050/domain

[bugzilla-daemon@xxxxxxxxxxxxxxxxxxx]

http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=487





------- Additional Comments From matta@xxxxxxxxxxxx  2006-02-20 15:23 -------
Yes I am running many domains.  I believe the peak is 55 on a single host. 
Average is 40-50.  It depends on what size plans are ordered and placed on a
specific host node. Ewan is familiar with my setup a bit and he has been on a
host node so you may want to discuss with him.  He does have a corrupt tdb file
I believe.

No I do not have a test case.  It definitely appears to happen more frequently
on new servers where users are still "playing" with their virtual machines and
hence there are many more xm create/shutdown/destroy/sysrq commands being 
executed.

Yes I am doing many xm commands in parallel.  For my service users have access
to a control panel where they can perform reboots, etc so in theory 50 xm
creates could all be performed at the same time.

I do not know Python at all so I don't know how much help I can be (I'm a
Perl/PHP guy). I am looking in tdb_store function and I see it IS locked at what
looks to be the most proper places. A few comments.

- This indicates that perhaps invalid values are being sent to tdb_store and
better error checking on the variables themselves to make sure they comform to
what is expected needs to be done.
- tdb_store may not be the problem, the tdb_delete_hash, tdb_nextkey, etc may
need to be locked earlier / later in the code.
- a modification that is attempted fails due to the store being locked, while
the hypervisor itself has already done it's work. I am not so sure on this one
as I don't know what order things are done in or if a store manipulation that
fails due to a locked tdb fails or keeps on re-trying until it gains the lock.

-- 
Configure bugmail: 
http://bugzilla.xensource.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

_______________________________________________
Xen-bugs mailing list
Xen-bugs@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-bugs