From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FeYjl-0003ye-OL for qemu-devel@nongnu.org; Fri, 12 May 2006 10:35:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FeYjk-0003xh-Hn for qemu-devel@nongnu.org; Fri, 12 May 2006 10:35:25 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FeYjk-0003xe-FX for qemu-devel@nongnu.org; Fri, 12 May 2006 10:35:24 -0400 Received: from [209.234.73.39] (helo=narn.hozed.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FeYlU-0004ez-Oj for qemu-devel@nongnu.org; Fri, 12 May 2006 10:37:12 -0400 Date: Fri, 12 May 2006 09:35:22 -0500 From: Troy Benjegerdes Subject: Re: [Qemu-devel] PATCH: Support for multi-file raw images Message-ID: <20060512143517.GL15855@narn.hozed.org> References: <1147329045.17542.15.camel@moonpix.desrt.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <1147329045.17542.15.camel@moonpix.desrt.ca> Reply-To: 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 Thu, May 11, 2006 at 02:30:45AM -0400, Ryan Lortie wrote: > Hello. > > Attached is a C file (and small patch) to add support for multi-file raw > images to QEMU. The rationale (for me at least) is as follows: > > I use rsync to backup my home directory. The act of starting up QEMU > changes a 20GB file on my drive. This causes 20GB of extra copying next > time I do backups. If I could split the drive image into smaller parts > (maybe 2048 10MB files) then the amount of extra copying is drastically > reduced (since only a few of these files are modified). > > There are definitely other reasons that this may be useful. Have you tried making a read-only 'base' image and using qcow images instead? I'm not convinced that splitting things up is going to help a lot. You might end up writing 1 512 byte block each to 500 files.. in the qcow image case, that is writing 256K, and with 10mb files, that's 5GB. > o If the files comprising the device are deleted (for example) while > QEMU is running then this is quite bad. Currently this will result > in read/write requests returning -1. Maybe it makes sense to panic > and cause QEMU to exit. > at the very least, the console should print an error. If you can keep all the files open, deleting the file won't be a problem.