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 -- ----------------- [EMAIL PROTECTED] ------------------ "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