hurd/running/qemu/writeback_caching: New.

7 files changed, 113 insertions, 111 deletions

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)