On 10/17/2013 07:09 PM, Chris Murphy wrote: > > On Oct 17, 2013, at 10:22 AM, Chris Murphy <li...@colorremedies.com> wrote: > >> >> So whatever options virt-manager is using to create qcow2 files, is either >> the same as -o preallocation=metadata,compat=1.1,lazy_refcounts=on, or any >> difference in options isn't making a difference in performance. The 37 >> second performance difference is probably due to less disk contention from >> the source ISO being on a separate drive this time around. And if I'm right >> about all of that, then the overwhelming gain is coming from unsafe cache. > > My original 1h41s result I reported was based on a qcow2 file that I made > using qemu-img without metadata preallocation, not the virt-manager UI. So > the above assertion that most gain is coming from unsafe cache was premature. > > Here's the retesting: > > btrfs partitions default guided to qcow2 (libvirt unsafe cache, virt-manager > default qcow2 creation) > anaconda.log "Running Thread: AnaInstallThread" = 15:56:02 > anaconda.log "Thread Done: AnaConfigurationThread" = 16:12:46 > 00:16:44 > > btrfs partitions default guided to qcow2 (libvirt unsafe cache, qemu-img > qcow2 creation with no options) > anaconda.log "Running Thread: AnaInstallThread" = 17:18:10 > anaconda.log "Thread Done: AnaConfigurationThread" = 17:35:23 > 00:17:13 > > That's significantly more justification to suggest most of the gain over the > first 1h41m case was overwhelming due to the use of the 'none' cache setting; > and qcow2 metadata preallocation is not nearly as significant a factor.
Yes preallocation=metadata makes a huge difference. I've testing benchmarks here: https://blueprints.launchpad.net/nova/+spec/preallocated-images Note the caveats with backing disk though. thanks, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
