From: Ming Zhang <mingz@ele.uri.edu>
To: device-mapper development <dm-devel@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [dm-devel] [RFC] dm-userspace
Date: Wed, 26 Apr 2006 18:55:28 -0400 [thread overview]
Message-ID: <1146092129.14129.333.camel@localhost.localdomain> (raw)
In-Reply-To: <87u08g553l.fsf@caffeine.beaverton.ibm.com>
just curious, will the speed be a problem here? considering each time it
needs to contact user space for mapping a piece of data. and the size
unit is per sector in dm?
do u have any benchmark results about overhead?
ming
On Wed, 2006-04-26 at 15:45 -0700, Dan Smith wrote:
> Xen needs to be able to directly access disk formats such as QEMU's
> qcow, VMware's vmdk, and possibly others. Most of these formats are
> based on copy-on-write ideas, and thus have a base image and a bunch
> of modified blocks stored elsewhere. Presenting this to a virtual
> machine transparently as a normal block device would be ideal. The
> solution I propose is to use device-mapper for redirecting block
> accesses to the appropriate locations within either the base image or
> the COW space, with the following constraints:
>
> 1. The block-allocation algorithm and formatting scheme should not be
> in the kernel. This gives the most flexibility and puts the
> complexity in userspace.
> 2. Actual data flow should happen only in the kernel, and userspace
> should be able to control it without the blocks being passed back
> and forth.
>
> So, I developed a generic device-mapper target called dm-userspace
> which allows a userspace application to control the block mapping in a
> mostly generic way. With the functionality it provides, I was able to
> write a userspace daemon that handles the mapping of blocks such that
> a qcow file could be presented as a single block device, mounted and
> accessed as if it were a normal disk. If/when VMware releases their
> vmdk spec under the GPL, adding support for it would be relatively
> simple. This would give us a unified block device to export to the
> virtual machine, that would be backed by a complex format such as vmdk
> or qcow.
>
> In addition to providing support for the above scenario, dm-userspace
> could be used for other things as well. It's possible that new
> device-mapper targets could be developed in userspace using a special
> application that used dm-userspace to simulate the kernel
> environment. Additionally, filesystem debuggers may be able to use
> dm-userspace to provide interactive control and logging of disk
> writes.
>
> A patch against 2.6.16.9 to add dm-userspace to the kernel is
> available here:
>
> http://static.danplanet.com/dm-userspace/dmu-2.6.16.9.patch
>
> After you have a patched kernel, you can build the (very tiny) helper
> library and example program, available here:
>
> http://static.danplanet.com/dm-userspace/libdmu-0.1.tar.gz
>
> Comments would be appreciated :)
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2006-04-26 22:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-26 22:45 [RFC] dm-userspace Dan Smith
2006-04-26 22:55 ` Ming Zhang [this message]
2006-04-26 23:07 ` [dm-devel] " Dan Smith
2006-04-26 23:41 ` Ming Zhang
2006-04-27 2:22 ` Dan Smith
2006-04-27 13:09 ` Ming Zhang
2006-05-09 23:02 ` Dan Smith
2006-05-10 13:27 ` Ming Zhang
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=1146092129.14129.333.camel@localhost.localdomain \
--to=mingz@ele.uri.edu \
--cc=dm-devel@redhat.com \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox