On Oct 17, 2013, at 1:57 PM, Pádraig Brady <p...@draigbrady.com> wrote:
> 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. The OS install times I'm experiencing don't support that conclusion for all workloads. 17m13s is not hugely different from 16m44s, and that's without preallocation vs preallocation=metadata. However 1h41m vs either of those is hugely different, and that came just between caching none vs unsafe. I haven't tested other caching methods yet. 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
