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 <kw...@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
