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.


Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Reply via email to