On Mon, Jul 30, 2012 at 1:10 PM, Mark Moseley <moseleymark@xxxxxxxxx> wrote: > 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. Anybody want to take a stab at this? I can cross-post if this isn't the best place for it. The QEMU list didn't seem like the right place (judging by the # of mentions of "qcow" on it). -- 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
