RBD volumes created with reversed stripe_unit and stripe_count parameters
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | libvirt |
Fix Released
|
Medium
|
||
| | libvirt (Ubuntu) |
High
|
Unassigned | ||
| | Trusty |
High
|
Unassigned | ||
Bug Description
=======
SRU Justification:
1. Impact: very slow rbd volumes
2. Test case: see below (create an RBD volume and check the stripe unit and count)
3. Regression potential: the patch simply fixes the argument order in a fn call and does nothing else, so there should be no regressions.
=======
Copied from upstream bug at https:/
"When creating an RBD volume with 'virsh vol-create-as', the newly created volume gets a stripe unit of 1 byte and a stripe count of 4194304. This results in an RBD volume which is unusably slow (in my tests, it took over 30 minutes for GRUB to load in an affected guest)."
This bug has been fixed upstream for libvirt 1.2.4, but the fix has not been backported for trusty-updates. This means this functionality is broken and unusable in the current LTS.
|
|
#10 |
Will be in 1.2.4 release
commit 4cd508ba4fc3cc3
Author: Steven McDonald <email address hidden>
Date: Tue Apr 29 12:19:01 2014 +1000
storage_
The stripe_unit and stripe_count arguments are passed to rbd_create3 in
the wrong order, resulting in a stripe size of 1 byte with 4194304
stripes on newly created RBD volumes.
https:/
Signed-off-by: Steven McDonald <email address hidden>
| Launchpad Janitor (janitor) wrote : | #1 |
Status changed to 'Confirmed' because the bug affects multiple users.
| Changed in libvirt (Ubuntu): | |
| status: | New → Confirmed |
| information type: | Public → Public Security |
| description: | updated |
| Changed in libvirt (Ubuntu): | |
| importance: | Undecided → High |
| status: | Confirmed → Triaged |
| Changed in libvirt (Ubuntu): | |
| status: | Triaged → Fix Released |
| Changed in libvirt (Ubuntu Trusty): | |
| importance: | Undecided → High |
| description: | updated |
Hello Florian, or anyone else affected,
Accepted libvirt into trusty-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-
Further information regarding the verification process can be found at https:/
| Changed in libvirt (Ubuntu Trusty): | |
| status: | New → Fix Committed |
| tags: | added: verification-needed |
| Serge Hallyn (serge-hallyn) wrote : | #3 |
@Florian,
is it possible for you to verify this bugfix in trusty-proposed?
| Chris J Arges (arges) wrote : | #4 |
Before:
$ sudo rbd info libvirt-pool/test
rbd image 'test':
size 10240 MB in 2560 objects
order 22 (4096 kB objects)
block_name_prefix: rbd_data.
format: 2
features: layering, striping
stripe unit: 1 bytes
stripe count: 4194304
After:
$ sudo rbd info libvirt-pool/test2
rbd image 'test2':
size 10240 MB in 2560 objects
order 22 (4096 kB objects)
block_name_prefix: rbd_data.
format: 2
features: layering, striping
stripe unit: 4096 kB
stripe count: 1
Verified.
| tags: |
added: verification-done removed: verification-needed |
| Chris J Arges (arges) wrote : | #5 |
Hello Florian, or anyone else affected,
Accepted libvirt into trusty-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-
Further information regarding the verification process can be found at https:/
| tags: | removed: verification-done |
| tags: | added: verification-needed |
| Timo Aaltonen (tjaalton) wrote : | #6 |
fixed the tag, this was verified already
| tags: |
added: verification-done removed: verification-needed |
| Launchpad Janitor (janitor) wrote : | #7 |
This bug was fixed in the package libvirt - 1.2.2-0ubuntu13
---------------
libvirt (1.2.2-
* Drop Support-
verification.
libvirt (1.2.2-
* Support-
* qemu-filterref-
interfaces (LP: #1448205)
* storage_
arguments to rbd_create3. (LP: #1447030)
-- Serge Hallyn <email address hidden> Thu, 18 Jun 2015 14:21:06 -0500
| Changed in libvirt (Ubuntu Trusty): | |
| status: | Fix Committed → Fix Released |
| Chris J Arges (arges) wrote : Update Released | #8 |
The verification of the Stable Release Update for libvirt has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
| Changed in libvirt: | |
| importance: | Unknown → Medium |
| status: | Unknown → Fix Released |


Description of problem:
When creating an RBD volume with 'virsh vol-create-as', the newly created volume gets a stripe unit of 1 byte and a stripe count of 4194304. This results in an RBD volume which is unusably slow (in my tests, it took over 30 minutes for GRUB to load in an affected guest).
How reproducible:
Run the following on an RBD-enabled system:
virsh vol-create-as $RBD_POOL test 10G
rbd info $RBD_POOL/test
Actual results:
'rbd info' reports a stripe unit and count as described above.
Expected results:
The stripe unit should be 4 MiB, and the stripe count should be 1.
Additional info:
This is caused by incorrect parameter ordering on line 495 of src/storage/ storage_ backend_ rbd.c. libvirt passes stripe_count before stripe_unit to rbd_create3, but the order of these parameters in librbd.h has stripe_unit before stripe_count. Thus, these parameters end up being reversed.
I will be sending a trivial patch which fixes this problem to the libvirt mailing list shortly.