From: Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
To: Laurent Vivier <Laurent.Vivier-6ktuUTfB/bM@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
Subject: Re: [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 [thread overview]
Message-ID: <478E1B57.7090609@codemonkey.ws> (raw)
In-Reply-To: <1200443443.4602.32.camel@frecb07144>
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
>
-------------------------------------------------------------------------
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
WARNING: multiple messages have this Message-ID (diff)
From: Anthony Liguori <anthony@codemonkey.ws>
To: Laurent Vivier <Laurent.Vivier@bull.net>
Cc: kvm-devel@lists.sourceforge.net, qemu-devel@nongnu.org
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 [thread overview]
Message-ID: <478E1B57.7090609@codemonkey.ws> (raw)
In-Reply-To: <1200443443.4602.32.camel@frecb07144>
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
>
next prev parent reply other threads:[~2008-01-16 14:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-15 18:22 [RFC][PATCH] Modify loop device to be able to manage partitions of the image disk Laurent Vivier
2008-01-15 18:22 ` [Qemu-devel] " Laurent Vivier
[not found] ` <120042137328-git-send-email-Laurent.Vivier-6ktuUTfB/bM@public.gmane.org>
2008-01-15 18:27 ` Daniel P. Berrange
2008-01-15 18:27 ` [Qemu-devel] Re: [kvm-devel] " Daniel P. Berrange
[not found] ` <20080115182745.GY17783-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-01-15 23:40 ` [Qemu-devel] " Laurent Vivier
2008-01-15 23:40 ` [Qemu-devel] Re: [kvm-devel] " Laurent Vivier
2008-01-15 23:54 ` [Qemu-devel] " Daniel P. Berrange
2008-01-15 23:54 ` [Qemu-devel] Re: [kvm-devel] " Daniel P. Berrange
[not found] ` <20080115235438.GB30528-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-01-16 0:30 ` [Qemu-devel] " Laurent Vivier
2008-01-16 0:30 ` [Qemu-devel] Re: [kvm-devel] " Laurent Vivier
2008-01-16 14:57 ` Anthony Liguori [this message]
2008-01-16 14:57 ` [kvm-devel] [Qemu-devel] " Anthony Liguori
[not found] ` <478E1B57.7090609-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
2008-01-16 15:55 ` Laurent Vivier
2008-01-16 15:55 ` [kvm-devel] " Laurent Vivier
2008-01-16 11:51 ` [Qemu-devel] [RFC][PATCH] Modify loop device to be able to managepartitions " Sergey Bychkov
2008-01-16 12:51 ` Laurent Vivier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=478E1B57.7090609@codemonkey.ws \
--to=anthony-rdkfgonbjusknkdkm+me6a@public.gmane.org \
--cc=Laurent.Vivier-6ktuUTfB/bM@public.gmane.org \
--cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.