Re: [Qemu-devel] [PATCH] qcow2: Add full image preallocation option

["Daniel P. Berrange" <berrange@redhat.com>]

On Fri, Jan 28, 2011 at 09:22:47AM +0100, Kevin Wolf wrote:
> Am 27.01.2011 16:58, schrieb Daniel P. Berrange:
> > On Thu, Jan 27, 2011 at 04:52:14PM +0100, Kevin Wolf wrote:
> >> This adds a preallocation=full mode to qcow2 image creation, which does not
> >> only allocate metadata for the whole image, but also writes zeros to it,
> >> creating a non-sparse image file.
> >>
> >> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> 
> > Is there a way you can calculate the total size of the qcow2
> > file upfront, and just use a single posix_fallocate() call to
> > do the zero-filled allocation of all the data blocks. It is
> > many orders of magnitude faster than truely writing blocks of
> > zero'd data on modern filesystems.  I guess if you're using
> > compression or encryption, we'd really have to go the slow
> > path, but for regular usage it'd be better to take a fast
> > path.
> 
> Encryption doesn't really change anything with respect to cluster
> allocations, but combining compression with preallocation doesn't make
> any sense. We should probably forbid that.
> 
> To get the size of the image, it should be enough to get the offset of
> the last cluster as the allocation is done sequentially. However, we
> don't have a bdrv_fallocate (yet). I'm not sure how to emulate this for
> drivers that don't support it directly, but maybe we could just ignore
> it for them.

FWIW in libvirt code we ended up with 'posix_fallocate()' as our
first choice. If that wasn't available, then we do a sequence of
'ftruncate()+mmap()+memset()+munmap()' for the region as second
choice. And if mmap doesn't exist, as the catch-all portable
option for any OS we do a write() of 1MB chunks in a loop.

Regards,
Daniel