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.
Tags for this post: openstack qemu ephemeral mkfs swap speed canonicalRelated posts: Further adventures with base images in OpenStack; Openstack compute node cleanup; Taking over a launch pad project; Speed limit; Slow git review uploads?; My machine was thrashing a lot; Large inodes = faster samba; Are you in a LUG? Do you want some promotional materials for LCA 2013?; Announcement video; linux.conf.au Returns to Canberra in 2013; Linux USB quandary
CommentSyndicated 2012-02-03 17:16:00 from stillhq.com : Mikal, a geek from Canberra living in Silicon Valley (no blather posts)