From: Dan Smith <danms@us.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: device-mapper development <dm-devel@redhat.com>
Subject: [RFC] dm-userspace
Date: Wed, 26 Apr 2006 15:45:02 -0700 [thread overview]
Message-ID: <87u08g553l.fsf@caffeine.beaverton.ibm.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2368 bytes --]
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 :)
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@us.ibm.com
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
next reply other threads:[~2006-04-26 22:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-26 22:45 Dan Smith [this message]
2006-04-26 22:55 ` [dm-devel] " Ming Zhang
2006-04-26 23:07 ` 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=87u08g553l.fsf@caffeine.beaverton.ibm.com \
--to=danms@us.ibm.com \
--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
all inboxes | Powered by JetHome®