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

[Anthony Liguori <anthony@codemonkey.ws>]

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
>