Bug 1097359
| Summary: | virt-sparsify hangs with 'No space left on device' while filling LV | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Bryn M. Reeves <bmr> | ||||
| Component: | libguestfs | Assignee: | Pino Toscano <ptoscano> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.5 | CC: | huzhan, leiwang, mbooth, perobins, ptoscano, rjones, yuliu | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | libguestfs-1.20.11-7.el6 | Doc Type: | Bug Fix | ||||
| Doc Text: |
Cause: virt-sparsify does not check for free space available in the temporary directory.
Consequence: virt-sparsify hangs if the temporary directory has not enough free space.
Fix: virt-sparsify checks by default for available space before the sparsification.
Result: The user is warned by default when there is not enough free space in the temporary directory.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-10-14 06:35:23 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Bryn M. Reeves
2014-05-13 15:53:12 UTC
Created attachment 895191 [details]
output of 'virt-sparsify -v' for an el6 image with LIBVIRT_DEBUG=1 LIBVIRT_TRACE=1
Turns out this was due to the host root fs (containing /tmp) having insufficient space for the temporary image: # du -ch /tmp/sparsifyf518c3.qcow2 1.4G /tmp/sparsifyf518c3.qcow2 1.4G total The sparsify works fine with sufficient space available in /tmp; still it'd be nice if this failed cleanly in this situation rather than simply blocking (without -v there's no way to see what's actually going on and even then it's not immediately clear where the ENOSPC is coming from). The sparsify seems to be working fine now: Copy to destination and make sparse ... qemu-img convert -f qcow2 -O 'raw' '/tmp/sparsifyf518c3.qcow2' 'bmr-rhel6-vm1.img1' This is essentially another instance of https://bugzilla.redhat.com/show_bug.cgi?id=745576 Two things have improved upstream which make this less of a problem with more recent virt-sparsify than in RHEL 6.5: (1) virt-sparsify now checks how much space is available before starting and can warn or give a fatal error if there is not enough. The relevant commits are: 7c463ac477168df5d4e4eb472ba01fa18b89c1a6 5b278937dfd5177eaafcbc41830450ef5c0a2ab8 This feature was added in 1.23.14 and as far as I remember was not backported to any version of RHEL. (2) virt-sparsify --in-place (in libguestfs 1.26) lets you do in-place sparsification which doesn't require the huge temporary file. I'm leaving this bug open because I think we should consider a backport of the commits in (1) to RHEL 6. RHEL 7.1 will probably get a rebase to 1.26/1.28so we don't need a bug for that. Also ae2dd1a9e77b06ae9e7fc8ff47d8b5ea7331e0a9 is required. Version: Host: RHEL6.6(2.6.32-498.el6.x86_64) Libguestfs: libguestfs-1.20.11-10.el6.x86_64 Steps: 1. fill /tmp with some files. 2. virt-sparify -v file1 file2 3. check when the /tmp is full, some blocking info was gave out. Result: We can verify this bug as above. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1458.html |