diff options
Diffstat (limited to 'hurd/running/qemu')
| -rw-r--r-- | hurd/running/qemu/babhurd_image.mdwn | 3 | ||||
| -rw-r--r-- | hurd/running/qemu/discussion.mdwn | 96 | ||||
| -rw-r--r-- | hurd/running/qemu/microsoft_windows.mdwn | 13 | ||||
| -rw-r--r-- | hurd/running/qemu/writeback_caching.mdwn | 90 |
4 files changed, 100 insertions, 102 deletions
diff --git a/hurd/running/qemu/babhurd_image.mdwn b/hurd/running/qemu/babhurd_image.mdwn index 855e8f51..6a3bb30e 100644 --- a/hurd/running/qemu/babhurd_image.mdwn +++ b/hurd/running/qemu/babhurd_image.mdwn @@ -6,7 +6,8 @@ What this little Hurd image can do This is the README file accompanying a [disk\_image](http://draketo.de/dateien/hurd/bab-hurd-qemu-2008-10-29.img.tar.bz2) for [[running the GNU/Hurd via qemu|hurd/running/qemu]]. To run the disk image, -just use `qemu -m 512 disk_image.img`. +just use `qemu -m 512 -drive +cache=writeback,index=0,media=disk,file=disk_image.img`. You can find the custom *.bashrc* used to tell the user about it as well as this text itself in the Mercurial repository [hurd_intro](http://bitbucket.org/ArneBab/hurd_intro). diff --git a/hurd/running/qemu/discussion.mdwn b/hurd/running/qemu/discussion.mdwn index 1ce14b01..facb8a31 100644 --- a/hurd/running/qemu/discussion.mdwn +++ b/hurd/running/qemu/discussion.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011 Free -Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 +Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -50,95 +50,3 @@ The problem is actually that the linux block cache doesn't make any consistency between /dev/hda and /dev/hda6, so if you give /dev/hda to qemu, qemu writings won't be consistent with mounting /dev/hda6 in linux. You can give /dev/hda6 directly to qemu and it will be fine. - - -# Host-side Writeback Caching - -IRC, freenode, #hurd, 2011-06-07 - - <braunr> hm, i guess i should have used cache=writeback with kvm before - starting the debian installer :/ - <braunr> ah yes, much better - <braunr> this shows how poor the state of our I/O drivers and subsystem is - :/ - <antrik> indeed... still no clustered pageout :-( - <braunr> and no I/O scheduler either - <braunr> although an I/O scheduler has limited value without clustered - pageouts - <braunr> since one of its goals is to pack related I/O requests together eh - <braunr> i wonder if the wiki mentions using cache=writeback to speed up - qemu performances - <braunr> it would help those unable to use kvm a lot - <braunr> and even those running kvm too - <braunr> kvm -m $RAM \ -monitor stdio \ -drive - cache=writeback,index=0,media=disk,file=hd0.img \ - <braunr> etc.. - <braunr> the idea is that qemu doesn't open its disk file synchronously - <braunr> changes are queued in the host page cache before being flushed to - the disk image - <braunr> but if you brutally close your qemu instance, you're likely to - loose file system consistency - <braunr> ext2fs will think it has committed its metadata to the disk, but - the disk image won't be updated synchronously - <braunr> on my machine (which is quite fast), my kvm has installed debian - like 10 times faster than without the option - <antrik> braunr: I don't think killing qemu should hurt in this - case... probably only matters when the host machine dies - <braunr> antrik: ah yes, right - <braunr> it really makes everything faster, even downloading, since I/O - requests aren't interleaved between networking RPCs - <antrik> regarding I/O sheduler... this discussion came up before, but I - don't remember the outcome -- doesn't the glued Linux driver actually - come with one? - <braunr> i don't remember either - <antrik> braunr: err... I don't think interleaving has anything to do with - it... I guess it's simply the fact that downloading writes the result to - disk, which suffers from lacking clustered pageout like everything else - <antrik> (my internet connection is too slow though to notice :-) ) - <braunr> well, if there is no I/O during downloading, downloading is faster - :) - -IRC, freenode, #hurd, 2011-06-08 - - <braunr> youpi: does xen provide disk caching options ? - <youpi> through a blktap, probably - <braunr> ok - -([[microkernel/mach/gnumach/ports/Xen]], *Host-side Writeback Caching*.) - - <braunr> we should find the pages mentioning qemu on the wiki and add the - options to enable disk image caching - <braunr> it really makes the hurd run a lot faster - <braunr> as a workaround for emulators until I/O is reworked, ofc - -IRC, freenode, #hurd, 2011-06-09 - - <gnu_srs> braunr recommends to use writeback caching with kvm. Is this - really recommended with the frequent crashes I experience? - <youpi> provided that you terminate your kvm normaly (i.e. quitting it, not - killing it), there should be no difference - <jkoenig> I think the host's stability is what matters - <jkoenig> the data presumably sits in linux's cache even if qemu dies - violently - <gnu_srs> But the freezes I see force me to kill kvm :-( - <youpi> maybe kvm doesn't even do caching indeed, I don't know - <youpi> gnu_srs: you can quit even when frozen - <youpi> use the console - <youpi> (the kvm console) - <jkoenig> gnu_srs, "Writeback caching will report data writes as completed - as soon as the data is present in the host page cache. This is safe as - long as you trust your host. If your host crashes or loses power, then - the guest may experience data corruption." (from the qemu manpage) - -IRC, freenode, #hurd, 2011-06-11 - - <gnu_srs> braunr: If you are online. For me setting the parameters -drive - cache=writeback,index=0,media=disk,file=hd0.img does not show any speed - improvement at all compared to the default. - <braunr> gnu_srs: what's your complete qemu command line ? - <gnu_srs> kvm -m 1024 -net nic,model=rtl8139 -net - user,hostfwd=tcp::5556-:22 -drive - cache=writeback,index=0,media=disk,file=hd0.img -cdrom netinst.iso - <braunr> what qemu version ? - <gnu_srs> qemu-kvm 0.14.1+dfsg-1: Sorry, I cannot be online until - tomorrow again. diff --git a/hurd/running/qemu/microsoft_windows.mdwn b/hurd/running/qemu/microsoft_windows.mdwn index 832b4bef..e2c8636c 100644 --- a/hurd/running/qemu/microsoft_windows.mdwn +++ b/hurd/running/qemu/microsoft_windows.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2012 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] Welcome, This document is for getting you started in a few minutes. @@ -46,7 +47,5 @@ Welcome, This document is for getting you started in a few minutes. ## QEmu Image Hangs on Boot The Debian GNU/Hurd K16 QEmu image hangs during the boot process. You may have better luck by converting the image to qcow format - ..\qemu-0.9.0-x86\qemu-img.exe convert debian-hurd-k16-qemu.img -O - qcow debian-hurd-k16-qemu.qcow - ..\qemu-0.9.0-x86\qemu.exe -L ..\qemu-0.9.0-x86 -m 512 -hda - debian-hurd-k16-qemu.qcow -localtime -M pc + ..\qemu-0.9.0-x86\qemu-img.exe convert debian-hurd-k16-qemu.img -O qcow debian-hurd-k16-qemu.qcow + ..\qemu-0.9.0-x86\qemu.exe -L ..\qemu-0.9.0-x86 -m 512 -drive cache=writeback,index=0,media=disk,file=debian-hurd-k16-qemu.qcow -localtime -M pc diff --git a/hurd/running/qemu/writeback_caching.mdwn b/hurd/running/qemu/writeback_caching.mdwn new file mode 100644 index 00000000..c9c53e3e --- /dev/null +++ b/hurd/running/qemu/writeback_caching.mdwn @@ -0,0 +1,90 @@ +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 +Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Host-side Writeback Caching"]] + +[[!tag open_issue_documentation]] + +IRC, freenode, #hurd, 2011-06-07 + + <braunr> hm, i guess i should have used cache=writeback with kvm before + starting the debian installer :/ + <braunr> ah yes, much better + <braunr> this shows how poor the state of our I/O drivers and subsystem is + :/ + <antrik> indeed... still no clustered pageout :-( + <braunr> and no I/O scheduler either + <braunr> although an I/O scheduler has limited value without clustered + pageouts + <braunr> since one of its goals is to pack related I/O requests together eh + <braunr> i wonder if the wiki mentions using cache=writeback to speed up + qemu performances + <braunr> it would help those unable to use kvm a lot + <braunr> and even those running kvm too + <braunr> kvm -m $RAM \ -monitor stdio \ -drive + cache=writeback,index=0,media=disk,file=hd0.img \ + <braunr> etc.. + <braunr> the idea is that qemu doesn't open its disk file synchronously + <braunr> changes are queued in the host page cache before being flushed to + the disk image + <braunr> but if you brutally close your qemu instance, you're likely to + loose file system consistency + <braunr> ext2fs will think it has committed its metadata to the disk, but + the disk image won't be updated synchronously + <braunr> on my machine (which is quite fast), my kvm has installed debian + like 10 times faster than without the option + <antrik> braunr: I don't think killing qemu should hurt in this + case... probably only matters when the host machine dies + <braunr> antrik: ah yes, right + <braunr> it really makes everything faster, even downloading, since I/O + requests aren't interleaved between networking RPCs + <antrik> regarding I/O sheduler... this discussion came up before, but I + don't remember the outcome -- doesn't the glued Linux driver actually + come with one? + <braunr> i don't remember either + <antrik> braunr: err... I don't think interleaving has anything to do with + it... I guess it's simply the fact that downloading writes the result to + disk, which suffers from lacking clustered pageout like everything else + <antrik> (my internet connection is too slow though to notice :-) ) + <braunr> well, if there is no I/O during downloading, downloading is faster + :) + +IRC, freenode, #hurd, 2011-06-08 + + <braunr> youpi: does xen provide disk caching options ? + <youpi> through a blktap, probably + <braunr> ok + +([[microkernel/mach/gnumach/ports/Xen]], *Host-side Writeback Caching*.) + + <braunr> we should find the pages mentioning qemu on the wiki and add the + options to enable disk image caching + <braunr> it really makes the hurd run a lot faster + <braunr> as a workaround for emulators until I/O is reworked, ofc + +IRC, freenode, #hurd, 2011-06-09 + + <gnu_srs> braunr recommends to use writeback caching with kvm. Is this + really recommended with the frequent crashes I experience? + <youpi> provided that you terminate your kvm normaly (i.e. quitting it, not + killing it), there should be no difference + <jkoenig> I think the host's stability is what matters + <jkoenig> the data presumably sits in linux's cache even if qemu dies + violently + <gnu_srs> But the freezes I see force me to kill kvm :-( + <youpi> maybe kvm doesn't even do caching indeed, I don't know + <youpi> gnu_srs: you can quit even when frozen + <youpi> use the console + <youpi> (the kvm console) + <jkoenig> gnu_srs, "Writeback caching will report data writes as completed + as soon as the data is present in the host page cache. This is safe as + long as you trust your host. If your host crashes or loses power, then + the guest may experience data corruption." (from the qemu manpage) |