[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH libvirt] storage: add preallocation element



On 05/17/2012 04:59 PM, Marc-André Lureau wrote:
> On Fri, May 18, 2012 at 12:13 AM, Eric Blake <eblake redhat com> wrote:
>> Meta-question - is pre-allocation something that is persistent with the
>> existence of the storage volume, or is it something that is one-shot at
>> the creation of the volume?
> 
>>From what I gather, there doesn't seem to be any flag telling you if
> the qcow2 was preallocated, although I guess there should be a way to
> somehow guess that.
> 
> I think I understand your point, and you may be right that a flag at
> creation time might be better. But, the fact that we can't easily know
> from the img itself if it was preallocated is also a loss of
> information. For example, if a user-friendly client wanted to warn the
> user of potential slowness due to a qcow2 image created without
> preallocation, it would be nice to keep that information somewhere, or
> perhaps implement that "guessing" at the "qemu-img info" level. But if
> we go that way, then why don't we query the image for all the data it
> has instead of storing them in the XML, such as capacity? Isn't
> allocation also a creation-time only value?

We _do_ query the image for all the data it has.  Capacity and
allocation _can_ change at runtime, and when they do, the storage volume
information _should_ reflect those changes.  That is, we don't store the
XML directly on disk, so much as regenerate it on the fly every time
someone asks for an API dealing with a storage volume.

Yeah, we're not the best at it right now (we need a 'virsh pool-refresh'
command to tell us to re-read image properties, and worse, reading
properties of a qcow2 file _while_ a qemu process is also modifying the
file is dangerous),  I'm hoping to improve that by adding better mapping
between domains and their storage volumes, and by making a storage
volume that is in use by an active domain defer to the domain
counterpart command for determining image usage.

Back to the question at hand - if there is a way to tell from qemu-img
if we have pivoted an image that was originally created without
preallocation into one that now uses the full space guaranteed as if it
had been pre-allocated, then that would indeed be useful information to
reflect back to the user in XML.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]