Re: LVM thin provisioning and virt-manager

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Oct 17, 2013, at 1:57 PM, Pádraig Brady <P@xxxxxxxxxxxxxx> wrote:

> On 10/17/2013 07:09 PM, Chris Murphy wrote:
>> 
>> On Oct 17, 2013, at 10:22 AM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux