summaryrefslogtreecommitdiff
path: root/hurd
diff options
context:
space:
mode:
Diffstat (limited to 'hurd')
-rw-r--r--hurd/running/debian/qemu_image.mdwn4
-rw-r--r--hurd/running/gnu/create_an_image.mdwn4
-rw-r--r--hurd/running/qemu.mdwn14
-rw-r--r--hurd/running/qemu/babhurd_image.mdwn3
-rw-r--r--hurd/running/qemu/discussion.mdwn96
-rw-r--r--hurd/running/qemu/microsoft_windows.mdwn13
-rw-r--r--hurd/running/qemu/writeback_caching.mdwn90
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)
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-03 05:18:26 +0000