Bug 584320

Summary: Cloning a guest image runs at a couple MB/min
Product: [Fedora] Fedora Reporter: James G. Brown III <james.brown>
Component: libvirtAssignee: Daniel Veillard <veillard>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 13CC: berrange, clalance, crobinso, itamar, james.brown, jforbes, pbatkowski, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-04-21 09:40:59 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description James G. Brown III 2010-04-21 07:50:00 EDT
Description of problem:

When trying to clone a guest through virt-manager the cloning process moves at a glacial pace of only a couple MB/min

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


How reproducible:


Steps to Reproduce:
1. F12 -> F13 upgrade with ext3 fs (possibly a F13 install with ext3 fs)
2. Create guest
3. Clone guest
Actual results:

cloning moves at about 1-2 MB/min 

Expected results:

Cloning of image takes ~approx. same time as it would to cp the filebacked img or whatever media you are using...

Additional info:

After further discussion this may be due to the fact that I've upgraded from F12 where I had an ext3 fs and apparently the following commit should fix this, although I haven't tested yet. 

commit e3c36a2575bc88a16d776693dc39ea01c780b406
Author: Jiri Denemark <jdenemar@redhat.com>
Date:   Tue Mar 16 16:03:59 2010 +0100
Use fsync() at the end of file allocation instead of O_DSYNC
Instead of opening storage file with O_DSYNC, make sure data are written to a disk only before we claim allocation has finished.

For others upgrading and running on an ext3 fs or for those that choose to install on ext3 as opposed to ext4 this could be a horrible black eye. The above commit if it does indeed resolve this should be backported to libvirt in F13 or at the very least a release note should be added to set expectations.
Comment 1 Cole Robinson 2010-04-21 09:40:59 EDT

*** This bug has been marked as a duplicate of bug 582356 ***