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 > ------------------------------------------------------------------------- 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
