On Wed, Apr 15, 2009 at 03:26:44PM -0400, Cole Robinson wrote:
Implement non-pool-blocking volume allocation for FS volumes.
We setup the volume object, then drop the pool lock, and start the
actual storage allocation. Certain pool operations will be blocked
(start, stop, destroy, refresh), but the basic things like volume
listings will still work.
This also allows storage allocation progress reporting: the API user can
watch the volume object in a separate thread, polling it's 'info' for
update to date capacity/allocation reporting.
Okay, that one is far more complex :-)
[...]
+ /* Make a shallow copy of the 'defined' volume
definition, since the
+ * original allocation value will change as the user polls 'info',
+ * but we only need the initial requested values
+ */
+ memcpy(buildvoldef, voldef, sizeof(*voldef));
+ voldef = NULL;
+
+ /* Drop the pool lock during volume allocation */
+ pool->asyncjobs++;
+ virStoragePoolObjUnlock(pool);
+
+ buildvoldef->building = 1;
+ buildret = backend->buildVol(obj->conn, buildvoldef);
+ buildvoldef->building = 0;
+
+ virStoragePoolObjLock(pool);
+ pool->asyncjobs--;
since buildvoldef->building is a condition, maybe it's safer to (un)set
it while the lock is taken.
I think the scheme works, but one thing we need to be careful about if
that if adding new operations they should also look at that ->building
condition.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit
http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/