From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
To: dm-devel@redhat.com
Subject: Re: [PATCH 1/2] Add userspace device-mapper target
Date: Fri, 9 Feb 2007 00:48:01 +0900 (JST) [thread overview]
Message-ID: <20070209004800A.fujita.tomonori@lab.ntt.co.jp> (raw)
In-Reply-To: <m3lkjltq1x.fsf@guaranine.beaverton.ibm.com>
From: Dan Smith <danms@us.ibm.com>
Subject: [dm-devel] [PATCH 1/2] Add userspace device-mapper target
Date: Mon, 29 Jan 2007 14:40:26 -0800
> This adds the dm-userspace kernel device-mapper target. It contains
> my latest changes, as well as Fujita's ringbuffer transport.
Some comments:
- The current ring buffer interface is the producer/consumer pointer
scheme. It's simple but it doesn't work for multi processes/threads.
Seems that kevent has a better ring buffer interface. And it's trying
to introduce new system calls for its ring buffer. They might work for
dm-user.
- DMU_FLAG_SYNC needs two round-trips between kernel and user
space. This leads to large latency (the poor performance of CoW).
DMU_FLAG_SYNC COW scheme (user space needs AIO writes to perform
another I/O from kernel) doen't sound good (dead lock prone).
With two minor modifications, dmu can do more efficiently, I think.
- enable an user-space to pass the kernel data to write
If you add u64 (user's address) to struct dmu_msg_map_response,
the kernel can map user's pages and add them to a bio. the write
is done in a zero-copy manner. A user-space process can simply
mmap a file and pass the address of the metadata (for CoW) to the
kernel. 2.6.20/drivers/scsi/scsi_tgt_lib.c does the same thing.
- Introduing DMU_FLAG_LINKED
If userspace uses DMU_FLAG_LINKED to ask the kernel to perform
multiple commands atomically and sequentially. For example, if
userspace needs to one data block and a metadata block (for the
data block) for CoW, userspace can send two dmu_msg_map_response
to the kernel. The former for the data block is with DMU_FLAG_LINKED and
the latter is for the metadata block (usespace uses the above
feature). The kernel performs two writes sequentially and then
completes the original I/O (endio).
DMU_FLAG_LINKED can be usefule for something like RAID
(possibly it would be better to split DMU_FLAG_LINKED into
DMU_FLAG_LINKED and DMU_FLAG_ORDERED).
next prev parent reply other threads:[~2007-02-08 15:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-29 22:40 [PATCH 1/2] Add userspace device-mapper target Dan Smith
2007-01-31 12:39 ` FUJITA Tomonori
2007-01-31 15:25 ` Dan Smith
2007-02-01 15:47 ` FUJITA Tomonori
2007-02-08 15:48 ` FUJITA Tomonori [this message]
2007-02-08 16:33 ` Dan Smith
2007-02-08 23:11 ` FUJITA Tomonori
2007-02-09 15:54 ` Dan Smith
2007-02-10 0:34 ` FUJITA Tomonori
2007-02-19 15:16 ` Dan Smith
2007-02-19 23:55 ` FUJITA Tomonori
2007-02-21 21:35 ` Dan Smith
2007-02-28 16:24 ` Dan Smith
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=20070209004800A.fujita.tomonori@lab.ntt.co.jp \
--to=fujita.tomonori@lab.ntt.co.jp \
--cc=dm-devel@redhat.com \
/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.