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 canonical
    Related posts: Further adventures with base images in OpenStack; Openstack compute node cleanup; Slow git review uploads?; Reflecting on Essex; Moving on; Folsom Dev Summit sessions

posted at: 17:16 | path: /openstack | permanent link to this entry