[dm-devel] [RFC] dm-writeboost: Porting daemon modulating migration from userland into the kernel
Akira Hayakawa
ruby.wktk at gmail.com
Mon Sep 16 11:49:03 UTC 2013
Joe,
> Is anyone using your new target other than you? You've posted on
> dm-devel, you've posted on lkml, has anyone bothered to try it?
Unfortunately, the answer is NO.
Some Japanese kernel developers once tried to use it
but didn't reached operation eventually.
But, I am feeling dm-writeboost gathering attention from storage engineers.
That I can not get 3rd party users right now is not because dm-writeboost is trivial.
I believe the target is worth merging in the future.
For example, dm-writeboost is discussed in the Russian website below
http://www.opennet.ru/opennews/art.shtml?num=37864
AND
also in Phoronix
http://phoronix.com/forums/showthread.php?84073-A-New-Log-Structured-Linux-Caching-Software-Driver#post354983
My conclusion is
there are potential users and I think I can greet them as users trying dm-writeboost
if the target is staged.
This issue of porting the userland daemon to in-kernel
is for them to use software of my best efforts.
If the design issue is raised again after all, all I can do it to nothing but fix it.
My regret is that I should have fixed this issue before proposal to staging tree.
PythonDaemon module being unstable was already found before that
although I didn't consider the design is bad.
Akira
More information about the dm-devel
mailing list