RE: [Qemu-devel] does ext4 cause problems? (not data loss)

[Joseph Miller]

> Hi,
>
>>I have the latest version of Ubuntu, Jaunty, and I have converted my fs
>> to
>>ext4.  Attempting to run a qcow image of WinXP Pro, backed by a qcow
>>image, on 0.10.3, even with kernel-kqemu is near impossible.  Commands:
>>
>>#!/bin/sh
>>
>>export QEMU_AUDIO_DRV=sdl
>>export SDL_VIDEODRVER=dga
>>sudo chmod 666 /dev/kqemu
>>/opt/qemu-0.10.3/bin/qemu -L /opt/qemu-0.10.3/share/qemu/ -kernel-kqemu
>>-hda winxp-200905.qcow -m 512 -usbdevice tablet -localtime -net
>>nic,model=rtl8139 -net user -soundhw sb16 -redir tcp:103389::3389
>>
>>My host computer spends most of its time doing disk writes and my guest
>> is
>>impossible to use.  The computer begins to boot, requests re-activation
>>(which I deny until I can get this straightened out) and then runs
>>slooooowly.  It does run, but I don't know why it is so slow.  One of the
>>reasons I upgraded to ext4 was to enjoy better Qemu performance.
>>
>>I have instead created a sparse file and formatted it with reiserfs
>> (which
>>on my crappy laptop gives very good qemu performance) and mounted it as a
>>loop filesystem.  Performance returns as expected and massive disk
>> writing
>>ceases.
>>
>>Anyone know what's up here?  Please CC me as I'm not on the list.
>> Thanks.
>
> Perhaps a link with that :
>
> http://lwn.net/Articles/327107/
>
> try to change your journaling mode to use "data=ordered".
> (see man mount(8) or tune2fs(8))
>
> Regards,
> Laurent
>
>
>
> --
> --------------------- address@hidden  ---------------------
> "Tout ce qui est impossible reste à accomplir"    Jules Verne
> "Things are only impossible until they're not" Jean-Luc Picard
>

Laurent,
Thanks, I will look into this.  I still would like to know, is this a
problem with the filesystem, or is there a better way for Qemu to be
flushing data to the disk?  I've seen the difference between fsync() and
fdatasync(), but really I don't even know if Qemu is using this or if this
is even the problem.  Maybe there could be a command line option to allow
for less reliability?  Many times I am using vm's as temporary testing
bases, with my disk image just over a backing image.  I keep the backing
file and delete the other images quite frequently, so data loss is not a
concern on these images.  When I'm ready for permanent changes, I can
commit to the backing file.  This provides me with high flexibility with
reasonable reliability on non-mission-critical systems.

Thanks,

-Joseph

Please CC me as I'm not on the list.