diff options
| -rw-r--r-- | contributing.mdwn | 6 | ||||
| -rw-r--r-- | hurd/running/debian/qemu_image.mdwn | 4 | ||||
| -rw-r--r-- | hurd/running/gnu/create_an_image.mdwn | 4 | ||||
| -rw-r--r-- | hurd/running/qemu.mdwn | 14 | ||||
| -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 | ||||
| -rw-r--r-- | microkernel/mach/gnumach/ports/xen.mdwn | 4 | ||||
| -rw-r--r-- | open_issues/gnumach_page_cache_policy.mdwn | 3 | ||||
| -rw-r--r-- | open_issues/qemu_writeback.mdwn | 18 | ||||
| -rw-r--r-- | unsorted/MakeImage.mdwn | 2 |
12 files changed, 122 insertions, 135 deletions
diff --git a/contributing.mdwn b/contributing.mdwn index 97ae450b..2f786e9f 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008, 2009, 2010, 2011 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 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 @@ -146,7 +146,7 @@ I'll have to think about it some more. * Install qemu-kvm via your distros packages. * Download the [qemu image](http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz): `wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz` * Unpack it: `tar xf debian-hurd.img.tar.gz` -* Run it: `qemu-kvm debian-hurd.img -m 512 -no-kvm-irqchip` # …irq… is a currently necessary fix due to some changes in Linux. Optionally use `--curses` to keep your keyboard layout. If need be modprobe kvm_amd, kvm intel and kvm to get kvm support (which is much, much faster). See also: [kvm FAQ](http://www.linux-kvm.org/page/FAQ). +* Run it: `qemu-kvm -m 512 -no-kvm-irqchip -drive cache=writeback,index=0,media=disk,file=debian-hurd.img` # …irq… is a currently necessary fix due to some changes in Linux. Optionally use `--curses` to keep your keyboard layout. If need be modprobe kvm_amd, kvm intel and kvm to get kvm support (which is much, much faster). See also: [kvm FAQ](http://www.linux-kvm.org/page/FAQ). * login as root * `apt-get update` * `apt-get install -y git mercurial emacs vim` diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn index 19b371c1..de1027b7 100644 --- a/hurd/running/debian/qemu_image.mdwn +++ b/hurd/running/debian/qemu_image.mdwn @@ -15,7 +15,9 @@ Usage: $ wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz $ tar -xz < debian-hurd.img.tar.gz - $ qemu -m 512 -net nic,model=rtl8139 -net user -hda debian-hurd-*.img + $ qemu -m 512 -net nic,model=rtl8139 -net user -drive cache=writeback,index=0,media=disk,file=$(echo debian-hurd-*.img) + +See the discussion about [[hurd/running/qemu/writeback_caching]]. Just in case you were wondering: the *root* password is *root*. diff --git a/hurd/running/gnu/create_an_image.mdwn b/hurd/running/gnu/create_an_image.mdwn index 8784a826..98af99eb 100644 --- a/hurd/running/gnu/create_an_image.mdwn +++ b/hurd/running/gnu/create_an_image.mdwn @@ -18,7 +18,7 @@ Creating a bootable qemu image from a root filesystem and bootloader 2. Use a live CD (better to have a lighter OS like system rescue CD to make the process faster) and the image created to boot. - qemu -m 512 -cdrom /dev/cdrom -hda <imagename.img> -boot d + qemu -m 512 -cdrom /dev/cdrom -drive cache=writeback,index=0,media=disk,file=<imagename.img> -boot d 3. Once system is booted use a partition editing tool (like fdisk, cfdisk, parted, gparted, qtparted ...) to partition the image. @@ -65,7 +65,7 @@ Creating a bootable qemu image from a root filesystem and bootloader 11. Run qemu to boot into your brand new system - qemu -m 512 -hda <hard disk image.img> -fda grub.img -boot a + qemu -m 512 -drive cache=writeback,index=0,media=disk,file=<hard disk image.img> -fda grub.img -boot a Happy Hacking !! diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index b64c576f..512ea602 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -12,6 +12,8 @@ License|/fdl]]."]]"""]] This page discusses things for [[Unix]] systems, there is a separate page for [[Microsoft_Windows]] systems. +See the discussion about [[hurd/running/qemu/writeback_caching]]. + # Readily Available Images You can use the following images to give the GNU/Hurd a try. @@ -29,7 +31,7 @@ volunteers and may not have been tested extensively. * [Disk image](http://draketo.de/dateien/hurd/bab-hurd-qemu-2008-10-29.img.tar.bz2) with a short intro on translators. Just start it with `qemu -m 512 - disk_image.img`. + -drive cache=writeback,index=0,media=disk,file=disk_image.img`. It should work without any of the configuration below. If you want to know what you can do with it, please have a look at [[its_wikipage|hurd/running/qemu/babhurd_image]]. And when you use it, please [tell me your experience with it](http://draketo.de/contact)! - [[community/weblogs/ArneBab]] @@ -125,7 +127,7 @@ First off you will need to create a disk image using `qemu-img`. I have set mine Next you will want to start up QEMU and begin the installation process. - $ qemu -m 512 -hda hd0.img -cdrom mini.iso -net nic,model=rtl8139 -net user + $ qemu -m 512 -drive cache=writeback,index=0,media=disk,file=hd0.img -cdrom mini.iso -net nic,model=rtl8139 -net user Now at his point do the regular install using `hd0` as your harddrive. Partition it and install the base system. @@ -175,7 +177,7 @@ Also see another text about how to [[gnu/create_an_image]] for the Starting qemu/qemu-kvm: - $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -hda hd0.img -vga vmware + $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -drive cache=writeback,index=0,media=disk,file=hd0.img -vga vmware vmsvga_value_write: guest runs Linux. Note: See below on port forwarding in the networking section. @@ -273,7 +275,7 @@ This is the recommended way to work with a Command Line Interface (CLI) since al a) with ssh (assuming you have installed openssh-server) - $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -hda hd0.img & + $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -drive cache=writeback,index=0,media=disk,file=hd0.img & Logging in to the running Hurd: @@ -290,7 +292,7 @@ Copying files: b) with telnet (assuming you have installed a telnet server, like telnetd) - $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5556-:23 -hda hurd-install.qemu & + $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5556-:23 -drive cache=writeback,index=0,media=disk,file=hurd-install.qemu & Logging in to the running Hurd: @@ -331,7 +333,7 @@ Now it is time to start-up your QEMU Hurd system and get networking going in the **Important:** Remember you may need to use the `-M isapc` or `-isa` flag if using an older version of the gnumach package. - $ qemu -m 512 -hda hd0.img -cdrom debian-K9-hurd-i386-CD1.iso -fda floppy.img -boot a -net nic -net tap + $ qemu -m 512 -drive cache=writeback,index=0,media=disk,file=hd0.img -cdrom debian-K9-hurd-i386-CD1.iso -fda floppy.img -boot a -net nic -net tap Once you have logged in as `root` run the `pfinet` translator with values that apply to your network. Think of your QEMU client as another computer in your network. 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) diff --git a/microkernel/mach/gnumach/ports/xen.mdwn b/microkernel/mach/gnumach/ports/xen.mdwn index 5fe73c06..c6023786 100644 --- a/microkernel/mach/gnumach/ports/xen.mdwn +++ b/microkernel/mach/gnumach/ports/xen.mdwn @@ -117,8 +117,8 @@ settrans -fgap /dev/hd0s1 /hurd/storeio -T typed part:1:device:hd0 # Host-side Writeback Caching -Optimization possible as it is with [[QEMU|hurd/running/qemu/discussion]], -*Host-side Writeback Caching*? +Optimization possible as it is with +[[QEMU|hurd/running/qemu/writeback_caching]]? IRC, freenode, #hurd, 2011-06-08 diff --git a/open_issues/gnumach_page_cache_policy.mdwn b/open_issues/gnumach_page_cache_policy.mdwn index 6f51d713..03cb3725 100644 --- a/open_issues/gnumach_page_cache_policy.mdwn +++ b/open_issues/gnumach_page_cache_policy.mdwn @@ -590,6 +590,9 @@ License|/fdl]]."]]"""]] <braunr> the amount of vm_object and ipc_port is gracefully adjusted <youpi> that'd help us with not having to tell people to use the complex -drive option :) + +([[hurd/running/qemu/writeback_caching]].) + <braunr> so you can easily run a hurd with 128 MiB with decent performance and no leak in ext2fs <braunr> yes diff --git a/open_issues/qemu_writeback.mdwn b/open_issues/qemu_writeback.mdwn deleted file mode 100644 index ab881705..00000000 --- a/open_issues/qemu_writeback.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -[[!meta copyright="Copyright © 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]]."]]"""]] - -[[!tag open_issue_documentation]] - - -# IRC, freenode, #hurdfr, 2012-07-01 - - <braunr> remplace "-hda file.img" par "-drive - cache=writeback,index=0,media=disk,file=file.img" - <braunr> tu sentiras tout de suite la différence diff --git a/unsorted/MakeImage.mdwn b/unsorted/MakeImage.mdwn index b3485771..ff64ce46 100644 --- a/unsorted/MakeImage.mdwn +++ b/unsorted/MakeImage.mdwn @@ -53,7 +53,7 @@ I use this for testing OSKit... ## <a name="Booting_Qemu"> Booting Qemu </a> - qemu -m 512 -user-net -isa -boot d -cdrom grub.iso -hda gnu.img + qemu -m 512 -user-net -isa -boot d -cdrom grub.iso -drive cache=writeback,index=0,media=disk,file=gnu.img The switch `-isa` is for current gnumach.gz on hda. |