[[!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. so, is there a way to use a Debian GNU/Hurd partition (/dev/hda6) with qemu directly? Don't dare to do that, please. It will lead to inconsistencies. Because the Linux kernel thinks that it has complete control over the disk, or something. 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. it's probably the same problem as having that partition mounted, suspending to disk, booting into it in the Hurd, and resume Linux right That's a different problem. Then the partitoon is still mounted. no, I think it is basically the same problem The file system stuff is cached in the kernel. you have data that has not been written to disk yet Right. and neither is prepared for the resource to be shared 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. 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? maybe adding -snapshot makes it totally safe azeem: Should be fine. 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. # Host-side Writeback Caching IRC, freenode, #hurd, 2011-06-07 hm, i guess i should have used cache=writeback with kvm before starting the debian installer :/ ah yes, much better this shows how poor the state of our I/O drivers and subsystem is :/ indeed... still no clustered pageout :-( and no I/O scheduler either although an I/O scheduler has limited value without clustered pageouts since one of its goals is to pack related I/O requests together eh i wonder if the wiki mentions using cache=writeback to speed up qemu performances it would help those unable to use kvm a lot and even those running kvm too kvm -m $RAM \ -monitor stdio \ -drive cache=writeback,index=0,media=disk,file=hd0.img \ etc.. the idea is that qemu doesn't open its disk file synchronously changes are queued in the host page cache before being flushed to the disk image but if you brutally close your qemu instance, you're likely to loose file system consistency ext2fs will think it has committed its metadata to the disk, but the disk image won't be updated synchronously on my machine (which is quite fast), my kvm has installed debian like 10 times faster than without the option braunr: I don't think killing qemu should hurt in this case... probably only matters when the host machine dies antrik: ah yes, right it really makes everything faster, even downloading, since I/O requests aren't interleaved between networking RPCs 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? i don't remember either 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 (my internet connection is too slow though to notice :-) ) well, if there is no I/O during downloading, downloading is faster :) IRC, freenode, #hurd, 2011-06-08 youpi: does xen provide disk caching options ? through a blktap, probably ok ([[microkernel/mach/gnumach/ports/Xen]], *Host-side Writeback Caching*.) we should find the pages mentioning qemu on the wiki and add the options to enable disk image caching it really makes the hurd run a lot faster as a workaround for emulators until I/O is reworked, ofc IRC, freenode, #hurd, 2011-06-09 braunr recommends to use writeback caching with kvm. Is this really recommended with the frequent crashes I experience? provided that you terminate your kvm normaly (i.e. quitting it, not killing it), there should be no difference I think the host's stability is what matters the data presumably sits in linux's cache even if qemu dies violently But the freezes I see force me to kill kvm :-( maybe kvm doesn't even do caching indeed, I don't know gnu_srs: you can quit even when frozen use the console (the kvm console) 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 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. gnu_srs: what's your complete qemu command line ? 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 what qemu version ? qemu-kvm 0.14.1+dfsg-1: Sorry, I cannot be online until tomorrow again.