Re: [kvm-devel] [Qemu-devel] Re: [RFC][PATCH] Modify loop device to be able to manage partitions of the image disk

[Anthony Liguori]

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
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>