From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CBChl-0004wT-75 for qemu-devel@nongnu.org; Sat, 25 Sep 2004 09:35:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CBChj-0004vs-Dm for qemu-devel@nongnu.org; Sat, 25 Sep 2004 09:35:12 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CBChi-0004vZ-Eg for qemu-devel@nongnu.org; Sat, 25 Sep 2004 09:35:10 -0400 Received: from [62.241.160.9] (helo=shockwave.systems.pipex.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CBCbC-00010V-9B for qemu-devel@nongnu.org; Sat, 25 Sep 2004 09:28:26 -0400 Received: from nowt.org (81-178-235-178.dsl.pipex.com [81.178.235.178]) by shockwave.systems.pipex.net (Postfix) with ESMTP id C70351C000F7 for ; Sat, 25 Sep 2004 14:28:23 +0100 (BST) Received: from wren.home (wren.home [192.168.1.7]) by nowt.org (Postfix) with ESMTP id C2238AC95 for ; Sat, 25 Sep 2004 14:28:14 +0100 (BST) From: Paul Brook Subject: Re: [Qemu-devel] qemu dd sizes Date: Sat, 25 Sep 2004 14:28:14 +0100 References: <20040925130826.83E68B6E0@xprdmailfe17.nwk.excite.com> In-Reply-To: <20040925130826.83E68B6E0@xprdmailfe17.nwk.excite.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409251428.14191.paul@codesourcery.com> 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 Saturday 25 September 2004 14:08, jmf wrote: > It's UFS, FreeBSD. I think UFS does a good job keeping all the data in a > non-sparse manner. > > > > I could resize the UFS partition down to a smaller size and then use dd, > however, I want a faster operation that will not alter my original > installation. I was hoping there is a way to manipulate the images that dd > produces, for more convenient use with qemu. On linux you can mount images using the loopback device. You may need to tell it to skip the partition table (the first track, usually 32256 bytes). I usually find it easier and more reliable to format/partition the image inside the guest, then mount it via loopback device on the host and use normal tools (cp, tar, etc) to copy the files across. Paul