I've been searching around trying to figure out if there's any benefit to having a qcow2 backing file created with preallocation=metadata set. That is, if there's any benefit to using a qcow2 file that is based on a qcow2 backing file with preallocation=metadata turned on. I know you can't turn on preallocation=metadata for the derived qcow2 file, but nothing seems to stop you from deriving an image from a base image where the base image has preallocation=metadata turned on. Sorry for the tongue twisters. Looking around the net, it's not super clear (or at least I'm not interpreting what I'm finding correctly) but it sounds like it shouldn't have any benefit, i.e. that you lose the benefit of the base image's preallocation=metadata on derived images. But goofing around with fio randrw, running tests on derived images from backing files with preallocation=metadata vs no preallocation=metadata, it seems to have a huge benefit, at least much much higher r/w bw with the preallocation=metadata-derived image. While I might've answered my own question, I'm no fio expert. I don't necessarily trust that I'm testing it correctly, which is why I'm asking here. Running the same test multiple times gives me 30-40meg/sec for both read and write on the preallocation=metadata-derived image, vs 0.5-1meg/sec for non-preallocation=metadata-derived images, both which sound way too high/low to be right. Same box (ubuntu 12.04 64-bit, running the stock ubuntu qemu 1.0), same disk, even the same directory. I could also see some bizarre side effect happening that I'm not aware of, ready to bite me later on down the road, like, say, that it's silently actually reading/writing the original image (just a made-up example). I also figured that it'd be good to ask for future googlers. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
