|
From: | Anthony Liguori |
Subject: | Re: [kvm-devel] [Qemu-devel] Re: [RFC][PATCH] Modify loop device to be able to manage partitions of the image disk |
Date: | Wed, 16 Jan 2008 08:57:27 -0600 |
User-agent: | Thunderbird 2.0.0.6 (X11/20071022) |
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 filesGood 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 canaccess 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 projecthad some working code providing a device mapper target calling out to a userspace daemon to handle non-raw file formats like qcow. I don'tknow 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
[Prev in Thread] | Current Thread | [Next in Thread] |