From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Bisjr-0005hm-I1 for qemu-devel@nongnu.org; Fri, 09 Jul 2004 06:36:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Bisjq-0005hC-9j for qemu-devel@nongnu.org; Fri, 09 Jul 2004 06:36:19 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bisjq-0005h8-6d for qemu-devel@nongnu.org; Fri, 09 Jul 2004 06:36:18 -0400 Received: from [62.253.162.46] (helo=mta06-svc.ntlworld.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BishG-0008Ee-QC for qemu-devel@nongnu.org; Fri, 09 Jul 2004 06:33:39 -0400 Received: from nemesis.frop.org ([62.253.132.150]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040709103347.PGDA9422.mta06-svc.ntlworld.com@nemesis.frop.org> for ; Fri, 9 Jul 2004 11:33:47 +0100 From: Julian Seward Subject: Re: [Qemu-devel] RFC for new features Date: Fri, 9 Jul 2004 11:34:58 +0100 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407091134.58693.jseward@acm.org> Reply-To: jseward@acm.org, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Friday 09 July 2004 11:02, Johannes Schindelin wrote: > Hi, > > On Thu, 8 Jul 2004, Thomas Munn wrote: > > 1. Definately a DISK manager/compressor ala vmware disk images (so I > > don't have to waste 4+gb if I don't have a full fileysystem!) > > Fabrice already mentioned that, right? I would favor using cloop devices, > i.e. using the toolset from cloop to create compressed "devices". Knoppix > uses this system to pack much more than 700MB on a CD. > > The advantage of cloop as compared to gzip'ed filesystem: Everytime you > seek in the file, with gzip you have to either have stored a certain zlib > state or decompress the whole file up to that point. With cloop this > problem is solved. I don't think it's a good idea to compress the real data in the filesystem it reduces performance and adds complexity. All that's needed is to modify the current cow disk system so that unused sectors don't take any (much) space in the .cow file _without_ having to rely on filesystems which support holes in files. vmware (afaik) doesn't really compress disk images, at least not compression in the gzip/zlib sense. What it does is understand the filesystem in the disk image, so it knows where the unused sectors are, and arranges for them to take more or less zero space in the .vmdk file. > The Ctrl-Shift-F2 monitor thing is a cute idea, but I really would like to > at least optionally retain the old style monitor. I agree it is a good idea. Mostly I just want to run WinXP without having to have a seperate xterm for the monitor, so I vote in favour of this one. J