Bug 1882582
| Summary: | Sparsify doesn't work on glusterfs | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Qin Yuan <qiyuan> | ||||
| Component: | General | Assignee: | Tomáš Golembiovský <tgolembi> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Qin Yuan <qiyuan> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 4.3.11.4 | CC: | ahadas, bpelled, bugs, lrotenbe | ||||
| Target Milestone: | ovirt-4.4.3-1 | Keywords: | Automation | ||||
| Target Release: | --- | Flags: | pm-rhel:
ovirt-4.4+
|
||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-10-21 09:13:48 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
It works fine for me. How exactly are you checking the size of disk before/after sparsify? Is it in web UI or using rest API or on storage? If it is using web UI then the 400 MB may be too small to be noticed because of the rounding and GB units. Also, what is the format of the disk? Is it raw or qcow? If it is qcow it may be the same issue we have on block storage domain where the disk is actually sparsified but the size of the qcow does not shrink and the apparent size stays the same. (In reply to Tomáš Golembiovský from comment #2) > It works fine for me. How exactly are you checking the size of disk > before/after sparsify? Is it in web UI or using rest API or on storage? If > it is using web UI then the 400 MB may be too small to be noticed because of > the rounding and GB units. Also, what is the format of the disk? Is it raw > or qcow? If it is qcow it may be the same issue we have on block storage > domain where the disk is actually sparsified but the size of the qcow does > not shrink and the apparent size stays the same. It runs `du -sh` on the SPM host to get the disk size, such as `du -sh /rhev/data-center/42f3fffa-e702-4259-a4df-855892e80a62/6be67fdd-506e-407d-b4f0-9758fc63b16c/images/482f20bc-94ee-492a-9aa5-f8e9817d6af0` The format of the disk is qcow. (In reply to Qin Yuan from comment #3) > (In reply to Tomáš Golembiovský from comment #2) > > It works fine for me. How exactly are you checking the size of disk > > before/after sparsify? Is it in web UI or using rest API or on storage? If > > it is using web UI then the 400 MB may be too small to be noticed because of > > the rounding and GB units. Also, what is the format of the disk? Is it raw > > or qcow? If it is qcow it may be the same issue we have on block storage > > domain where the disk is actually sparsified but the size of the qcow does > > not shrink and the apparent size stays the same. > > It runs `du -sh` on the SPM host to get the disk size, such as `du -sh > /rhev/data-center/42f3fffa-e702-4259-a4df-855892e80a62/6be67fdd-506e-407d- > b4f0-9758fc63b16c/images/482f20bc-94ee-492a-9aa5-f8e9817d6af0` > > The format of the disk is qcow. With `du` you should see the actual used size so the size should decrease after sparsification. I have tested it again to be sure and it works OK for me. Instead of using `-h` you could try to use `-B1` to get the size in bytes or increase the file size from 400 MB to 2 GB to make sure the result is not wrongly reported because of rounding. Retested on RHV 4.3, still the same result. Tested on RHV 4.4(4.4.3-8), it works fine. (In reply to Qin Yuan from comment #5) > Retested on RHV 4.3, still the same result. Tested on RHV 4.4(4.4.3-8), it > works fine. I assume it was tested on 4.4 using the original automation modified to run `du -B1`? 4.3 is in a blocker-only mode and this one would not be considered a blocker - so if the above is correct, that's good enough (In reply to Arik from comment #6) > (In reply to Qin Yuan from comment #5) > > Retested on RHV 4.3, still the same result. Tested on RHV 4.4(4.4.3-8), it > > works fine. > > I assume it was tested on 4.4 using the original automation modified to run > `du -B1`? It was tested on 4.4 using `du -sh`. > 4.3 is in a blocker-only mode and this one would not be considered a blocker > - so if the above is correct, that's good enough (In reply to Qin Yuan from comment #7) > It was tested on 4.4 using `du -sh`. Ack, so exactly the same test that failed on 4.3 passes on 4,4? (In reply to Arik from comment #8) > (In reply to Qin Yuan from comment #7) > > It was tested on 4.4 using `du -sh`. > > Ack, so exactly the same test that failed on 4.3 passes on 4,4? Yes. This can be reproduced manually on 4.3. OK, in that case I'd suggest to skip this test on 4.3 - even if there's an issue we won't be able to provide a fix for 4.3 at this point, let's concentrate on 4.4 If it's closed current release, it's fixed in 4.4.3. Re targeting accordingly. |
Created attachment 1716522 [details] engine.log Description of problem: When trying to sparsify VM disk created on glusterfs storage, it passed without sparsifying. Version-Release number of selected component (if applicable): ovirt-engine-4.3.11.4-0.1.el7.noarch vdsm-4.30.50-1.el7ev.x86_64 How reproducible: 100% Steps to Reproduce: 1. Create thin provisioned disk for vm in glusterfs storage. 2. Write a file on VM(dd if=/dev/urandom of=/var/tmp/test_file bs=1M count=400). 3. Delete the file on VM. 4. Shutdown VM and sparsify the disk. Actual results: 1. Sparsify passed, but the disk used space remain the same. Expected results: 1. Sparsify pass, and the disk used space change to be lower. Additional info: