[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] [RFC] dm-writeboost: Porting daemon modulating migration from userland into the kernel



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]