qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QEMU with KNOPPIX


From: John R. Hogerhuis
Subject: Re: [Qemu-devel] QEMU with KNOPPIX
Date: Thu, 26 Aug 2004 02:34:00 -0700

On Thu, 2004-08-26 at 00:57, Kuniyasu Suzaki wrote:

> Yes, root File System of KNOPPIX is stored to a compressed loop-back
> device. It is called "CLOOP". KNOPPIX has boot option to move CLOOP file
> to hard disk or RAM disk. It takes time to boot, but response makes
> better.
> 
> But I think the option is not valuable on QEMU. It makes slow boot on QEMU.
> To make short-cut of boot is most important.
> 

How long does it take to transfer the CLOOP file to hard disk?

I would think that you could do it just once, say and drop it in My
Documents, or wherever the user wants, with a pointer to the file in the
registry. Don't have the virtual machine do it (that's slow), have the
script that starts QEMU copy the file to the host's hard disk before
running QEMU. Also put a version number there. Then read some version
number off the Knoppix disk... if they match, and the file is already on
the hard drive don't copy it again. So you get a one-time hit, for
hopefully a big performance gain and the user won't see it again until a
new version of knoppix-qemu-win comes out (BTW, what is a good name for
this? kqw? something short... I actually registered a domain when I
thought of this possibility sometime back, "linsitu" if that makes any
sense to anyone...)

Might be a cool, general way to do this transparently in QEMU. What if
there was a option/feature in QEMU, that as it reads from a CD-ROM, it
builds a cache of it on the hard disk. Maybe it saves some unique info
from cd, and the hash for some random blocks. Then when QEMU is started
again with the same disk, it hashes those blocks and decides whether it
already has cached any/all of that cd on hard disk. If it has it reads
from cache of that cd on hard disk. Then you would have something that
could work with any bootable linux cd without any tweaking.

But booting a suspended image will probably save a lot of time so either
one is worth some focus.

I don't think the QEMU engine itself is off the hook either. There are
definitely things that could be squeezed there, the question is, is
there any low-hanging fruit which would provide a measurable performance
gain...

-- John.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]