Bug 444047 - F9 iozone w/ direct I/O performing higher than the raw device
F9 iozone w/ direct I/O performing higher than the raw device
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
9
x86_64 Linux
high Severity low
: ---
: ---
Assigned To: Daniel Veillard
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-24 14:53 EDT by John Shakshober
Modified: 2009-03-10 08:39 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-10 08:39:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description John Shakshober 2008-04-24 14:53:12 EDT
Description of problem:
Running IOzone to an fedora RHEL5 or f9 guest, adding -I flag for directI/O give
3-4x the performance of the raw device.  

Version-Release number of selected component (if applicable):
2.6.25-0.218.rc8.git7.fc9.x86_64 

How reproducible:

100%

Steps to Reproduce:
1. copy iozone kit http://people.redhat.com/dshaks/.kits/iozone-3-233.i386.rpm
2. moutn a data disk in the guest (either file or phy based) 
3. ./iozone -s 1g -r 64k -I -f /perf1
  
Actual results:
                
f9_base achieved             161 MB/sec
f9_fv 	in fv guest achieved 785 MB/sec

Expected results:
<= 161 MB/sec as it can't run faster than the raw device

Additional info:
Comment 1 Mark McLoughlin 2008-04-25 03:21:52 EDT
Just to make it clear for everyone reading - the issue with the fact that FV is
outperforming baremetal is that it implies that writes aren't being flushed to
the host's disk before being acknowledged which, in turn, means the guests could
be corrupted when something goes wrong.
Comment 2 Red Hat Bugzilla 2008-05-14 07:28:28 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 3 Daniel Berrange 2008-10-07 15:18:01 EDT
Core problem here is that libvirt is not setting the 'cache=off' flag to -drive argument when launching QEMU.
Comment 4 Daniel Berrange 2008-10-08 07:07:10 EDT
Patch posted

http://www.redhat.com/archives/libvir-list/2008-October/msg00180.html
Comment 5 Daniel Berrange 2009-03-10 08:39:57 EDT
libvirt now has the ability to set the caching mode in the XML for a disk, as of 0.6.0 release. So going to close this bug now.

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