Bug 506745 - libvirt fails to properly allocate sparse file with "allocation=0" for raw format type.
libvirt fails to properly allocate sparse file with "allocation=0" for raw fo...
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Daniel Veillard
Depends On:
  Show dependency treegraph
Reported: 2009-06-18 10:52 EDT by Harshavardhana
Modified: 2015-03-22 21:03 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-30 07:44:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Harshavardhana 2009-06-18 10:52:07 EDT
Description of problem:

with <allocation>0</allocation> with volume format type as "raw" libvirt tries to create several MB's of a raw file which is wrong, where as it should have created a few bytes of sparse file. 

Version-Release number of selected component (if applicable):

Latest libvirt git log "0e0e542af83557dade5c588a2098e4cb0536ab23"

How reproducible:

Using ovirt frontend with NFS configured in one of the storage pools. 

Steps to Reproduce:
1. Create 10G a volume on an existing pool of NFS with libvirt version pointing to latest git in the backend i.e ovirt-node-image requires libvirt to be of latest git. 
2. taskomatic deamon goes into waiting mode, until libvirt finishes its sparse file write. 
3. Results in taskomatic timeout and a failure in volume creation. 
Actual results:

A 1.2GB of file created in backend but due to timeout, the volume creation was stopped in bet'n. 

Expected results:

Volume file should have been few bytes rather than having around MB's and GB's. This would effect when a sufficiently loaded NFS server doesn't respond. 

Additional info:
Comment 1 Daniel Berrange 2009-07-30 07:44:41 EDT
Allocation of sparse files was fixed upstream in this commit

commit 5ea25b78010d9e00ff018078fbd690b5a24b54ce
Author: Cole Robinson <crobinso@redhat.com>
Date:   Mon Jun 22 16:33:24 2009 +0000

    Fix raw storage volume creation for allocation < capacity.
    CreateXMLFrom changes accidentally caused all raw volume creation to be
    fully allocated (as though allocation == capacity). Fix this.
    Also force CreateXMLFrom to maintain the previous behavior: sparseness
    should still be maintained since we search for holes when copying, and the
    clone behavior hasn't been tested with anything but the broken behavior.

This will be included in the 0.7.0 release

Note You need to log in before you can comment on or make changes to this bug.