[libvirt] [PATCH 3/3] Implement non-pool-blocking volume allocation for FS volumes

[Daniel Veillard]

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 at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/