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

[Laurent Vivier]

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

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
-- 
----------------- address@hidden  ------------------
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry

signature.asc
Description: Ceci est une partie de message numériquement signée