[dm-devel] dm-userspace (no in-kernel cache version)

[Dan Smith]

FT> Surely, we need to replace the request list with hash list.

I have done that now.  It helps performance quite a bit, although it
does not perform at the same level with lots of threads.  I'll keep
working on it.

FT> Another possible improvement is that simplifying dmu_ctl_write()
FT> by using kernel thread. Now the user-space daemon calls
FT> dmu_ctl_write() and does lots of work in kernel mode. It is better
FT> for a user-space daemon to just notify kernel of new events, go
FT> back to user space, and receive new events from kernel in SMP
FT> boxes. I like to create kernel threads, dmu_ctl_write just wakes
FT> up the threads, and they call dmu_event_recv().

Yes, I think this would be a good idea.

FT> Yep, I dropped some of the features because of my laziness, though
FT> if endio means that the kernel notifies user-space of I/O
FT> completion, I think that I implemented it.

We need more than just notification of endio, but also the ability to
delay the endio completion until userspace has acknowledged the
endio.  This is crucial for us to maintain metadata consistency in the
CoW case.

FT> One possible feature is support for multiple destinations. If user
FT> space can tell kernel to write multiple devices, we can implement
FT> kinda RAID daemons in user space.

Yes, my original version supported this, which would allow RAID from
userspace, as well as lots of other neat tricks :)

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms at us.ibm.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20060912/4daa089f/attachment.sig>