Move a bunch of IRC discussion logs to discussion subpages.

1 files changed, 52 insertions, 0 deletions

diff --git a/hurd/running/qemu/discussion.mdwn b/hurd/running/qemu/discussion.mdwn
new file mode 100644
index 00000000..fd0df4c5
--- /dev/null
+++ b/hurd/running/qemu/discussion.mdwn
@@ -0,0 +1,52 @@
+[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011 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]]
+
+# Using Partitions
+
+[[IRC]], #hurd, 2007-07-04.
+
+    <azeem-uni> so, is there a way to use a Debian GNU/Hurd partition
+      (/dev/hda6) with qemu directly?
+    <tschwinge> Don't dare to do that, please.
+    <tschwinge> It will lead to inconsistencies.
+    <tschwinge> Because the Linux kernel thinks that it has complete control
+      over the disk, or something.
+    <tschwinge> In theory you could run something like ``-hda /dev/hda'',
+      having GRUB installed on there to offer you to boot your Hurd system from
+      hda6 and that will even work, but then don't get the idea to stop qemu,
+      mount that partition on your Linux system and restart qemu.  That's where
+      I got lots of inconsistencies then, afterwards.
+    <azeem-uni> it's probably the same problem as having that partition
+      mounted, suspending to disk, booting into it in the Hurd, and resume
+      Linux
+    <neal> right
+    <tschwinge> That's a different problem.
+    <tschwinge> Then the partitoon is still mounted.
+    <neal> no, I think it is basically the same problem
+    <tschwinge> The file system stuff is cached in the kernel.
+    <neal> you have data that has not been written to disk yet
+    <tschwinge> Right.
+    <neal> and neither is prepared for the resource to be shared
+    <tschwinge> In the azeem-uni scenarion the data is on the file system layer
+      and in my scenarion it's some disk block caching inside the Linux kernel,
+      I guess.
+    <azeem-uni> anyway, do you guys think if I use -hda /dev/hda and tell Grub
+      to boot off /dev/hda6, that the rest of hda should be fine, right?
+    <azeem-uni> maybe adding -snapshot makes it totally safe
+    <neal> azeem: Should be fine.
+    <tschwinge> Yes.
+
+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.