From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JF9hl-0002iM-C9 for qemu-devel@nongnu.org; Wed, 16 Jan 2008 09:57:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JF9hk-0002g8-8L for qemu-devel@nongnu.org; Wed, 16 Jan 2008 09:57:24 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JF9hk-0002fu-3w for qemu-devel@nongnu.org; Wed, 16 Jan 2008 09:57:24 -0500 Received: from an-out-0708.google.com ([209.85.132.244]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JF9hj-0002yd-IM for qemu-devel@nongnu.org; Wed, 16 Jan 2008 09:57:23 -0500 Received: by an-out-0708.google.com with SMTP id b38so86135ana.130 for ; Wed, 16 Jan 2008 06:57:21 -0800 (PST) Message-ID: <478E1B57.7090609@codemonkey.ws> Date: Wed, 16 Jan 2008 08:57:27 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [kvm-devel] [Qemu-devel] Re: [RFC][PATCH] Modify loop device to be able to manage partitions of the image disk References: <120042137328-git-send-email-Laurent.Vivier@bull.net> <20080115182745.GY17783@redhat.com> <1200440406.4602.16.camel@frecb07144> <20080115235438.GB30528@redhat.com> <1200443443.4602.32.camel@frecb07144> In-Reply-To: <1200443443.4602.32.camel@frecb07144> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Vivier Cc: kvm-devel@lists.sourceforge.net, qemu-devel@nongnu.org Laurent Vivier wrote: > Le mardi 15 janvier 2008 à 23:54 +0000, Daniel P. Berrange a écrit : > >> On Wed, Jan 16, 2008 at 12:40:06AM +0100, Laurent Vivier wrote: >> >>> Le mardi 15 janvier 2008 à 18:27 +0000, Daniel P. Berrange a écrit : >>> >>>> On Tue, Jan 15, 2008 at 07:22:53PM +0100, Laurent Vivier wrote: >>>> >>>>> As it should be useful to be able to mount partition from a >>>>> disk image, (and as I need a break in my bug hunting) I've >>>>> modified the loop driver to mount raw disk image. >>>>> >>>>> To not break original loop device, as we have to change minor >>>>> numbers to manage partitions, a new parameter is added to the module: >>>>> >>>> I don't see the point in modifying the loop device driver when you >>>> can already access the partitions with existing device mapper >>>> functionality & tools. >>>> >>> There are two reasons: >>> >>> 1- I didn't know kpartx (thank you for the tip) >>> >>> but using loop device, you will be able to use all partition tables >>> known by the kernel (acorn, atari, efi, karma, mac, osf, sun, >>> ultrix, amiga, ibm, ldm, msdos, sgi, sysv68), whereas kpartx can use >>> only partition tables it knows (bsd, dasd, dos, mac, sun, efi, sun, >>> unixware). >>> >> This is an argument for extending kpartx to cope with the other >> partition tables :-) I have 50/50 split between VMs using files >> > > Good try... but IMHO, I think it is better to let the kernel decode the > partition table... > > >> vs VMs using LVM volumes - the loop driver patches only help you >> access partitions within a file based image, whereas kpartx can >> access the partitions within any block device, so can support >> files (via existing loop device) & LVM vols & nested partitions. >> > > I think you're wrong (but you seem to know the subject better than me, > so ...): you should be able to use the modified loop device on the > logical volume to decode partition table. > > >>> 2- I'd like to mount qcow2 or others disk image formats, so perhaps it's >>> easier to modify loop device driver (but perhaps you know another magic >>> tool ?) >>> >> There has been some work in this area wrt to Xen - the DM-Userspace project >> had some working code providing a device mapper target calling out to a >> userspace daemon to handle non-raw file formats like qcow. I don't >> know what the state of it is now wrt to upstream kernel / device-mapper, >> or even whether it is more than just 'proof of concept', but the project >> page is here with some info: >> >> http://wiki.xensource.com/xenwiki/DmUserspace FWIW, I still think a userspace block device is the Right Way to support these sort of things. dm-userspace turned out to be difficult as device mapper has some rather strict requirements about alignment that some formats (like qcow) cannot satisfy. The loop driver is a terrible base to start from as it does not preserve data integrity. Regards, Anthony Liguori >> It seems a very good idea, but what I don't like: >> - it seems very complex (like IBM guys like ;-) ) >> - it is one and a half year old >> >> To be honest, if something good already exists, I take it... >> >> Laurent >> > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > ------------------------------------------------------------------------ > > _______________________________________________ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel >