From: Dan Smith <danms@xxxxxxxxxx>
Subject: [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).
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
