hurd/running/qemu/writeback_caching: New.

1 files changed, 2 insertions, 94 deletions

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.