Wow, qemu-img is fast

I wanted to determine if its worth putting ephemeral images into the libvirt cache at all. How expensive are these images to create? They don’t need to come from the image service, so it can’t be too bad, right? It turns out that qemu-img is very very fast at creating these images, based on the very small data set of my laptop with an ext4 file system…

    mikal@x220:/data/temp$ time qemu-img create -f raw disk 10g
    Formatting 'disk', fmt=raw size=10737418240
    
    real	0m0.315s
    user	0m0.000s
    sys	0m0.004s
    
    mikal@x220:/data/temp$ time qemu-img create -f raw disk 100g
    Formatting 'disk', fmt=raw size=107374182400
    
    real	0m0.004s
    user	0m0.000s
    sys	0m0.000s
    

Perhaps this is because I am using ext4, which does funky extents things when allocating blocks. However, the only ext3 file system I could find at my place is my off site backup disks, which are USB3 attached instead of the SATA2 that my laptop uses. Here’s the number from there:

    $ time qemu-img create -f raw disk 100g
    Formatting 'disk', fmt=raw size=107374182400
    
    real	0m0.055s
    user	0m0.000s
    sys	0m0.004s
    

So still very very fast. Perhaps its the mkfs that’s slow? Here’s a run of creating a ext4 file system inside that 100gb file I just made on my laptop:

    $ time mkfs.ext4 disk
    mke2fs 1.41.14 (22-Dec-2010)
    disk is not a block special device.
    Proceed anyway? (y,n) y
    warning: Unable to get device geometry for disk
    Filesystem label=
    OS type: Linux
    Block size=4096 (log=2)
    Fragment size=4096 (log=2)
    Stride=0 blocks, Stripe width=0 blocks
    6553600 inodes, 26214400 blocks
    1310720 blocks (5.00%) reserved for the super user
    First data block=0
    Maximum filesystem blocks=0
    800 block groups
    32768 blocks per group, 32768 fragments per group
    8192 inodes per group
    Superblock backups stored on blocks:
    	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    	4096000, 7962624, 11239424, 20480000, 23887872
    
    Writing inode tables: done
    Creating journal (32768 blocks): done
    Writing superblocks and filesystem accounting information: done
    
    This filesystem will be automatically checked every 36 mounts or
    180 days, whichever comes first.  Use tune2fs -c or -i to override.
    
    real	0m4.083s
    user	0m0.096s
    sys	0m0.136s
    

That time includes the time it took me to hit the ‘y’ key, as I couldn’t immediately find a flag to stop prompting.

In conclusion, there is nothing slow here. I don’t see why we’d want to cache ephemeral disks and use copy on write for them at all. Its very cheap to just create a new one each time, and it makes the code much simpler.