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.