Bug 678050
Summary: | 'qemu-img create -f qcow2 -o preallocation=metadata ...' allocates the entire data on iSCSI | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Erez Shinan <erez> |
Component: | qemu-kvm | Assignee: | Kevin Wolf <kwolf> |
Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.1 | CC: | abaron, areis, bcao, danken, iheim, juzhang, kwolf, mkenneth, shu, tburke, virt-maint |
Target Milestone: | rc | Keywords: | Reopened |
Target Release: | 6.2 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-09-10 10:07:43 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 580954, 672346, 773650, 773651, 773665, 773677, 773696 |
Description
Erez Shinan
2011-02-16 16:01:44 UTC
Can you please test the performance of qcow2 w/ latest 6.1 code? We have lots of changes there and we might not need prealocation cmdline No response, closing, if I'm not mistaken it might not be possible on raw devices. Reopening. If you want to test qcow2 performance on 6.1/6.2 you should ask qemu qe or performance team, not rhevm qe / engineering. Indeed, you cannot preallocate the clusters on iscsi, but you can preallocate the tables so that all md will be located sequentially on disk.
> Indeed, you cannot preallocate the clusters on iscsi, but you can preallocate
> the tables so that all md will be located sequentially on disk.
Also, you could preallocate according to device size.
Could be nice actually to even do this during runtime (every time we make the device bigger, allocate mappings to added sections...
Btw Dor, even if performance improved in 6.2, it does not mean that preallocating would not improve performance even further which would make this bz worthwhile regardless of current qcow2 performance.
Note that Kevin said in kvm forum that qcow2 causes a 50% performance degradation...
What's your use case for this? If I'm not mistaken, formatting the image with a filesystem will already write to sectors close to the end to the image, so if this was implemented, you would only move the LV growth from image creation time to installation time. Which I guess doesn't make a big difference. Had a short email conversation with Ayal about this. For the reasons stated in comment 10 it's obvious that preallocating clusters isn't possible in this case. The open question was whether preallocating the L2 tables would make sense, and if we could take advantage of having all of them sequentially at the start of the image. We came to the conclusion that because we never read two tables at once, having them sequential doesn't help; and in the allocating case the cost of one additional 64k write for the new L2 table for each 512 MB of virtual disk size (assuming 64k clusters) would likely be lost in the noise, so an optimisation for this would be a wasted effort. There's much more to gain in other places. Therefore, I'm closing the bug again. |