| |||||||||||||
The conclusion of the 3.9 merge windowThe conclusion of the 3.9 merge windowPosted Mar 6, 2013 13:48 UTC (Wed) by ebirdie (subscriber, #512)In reply to: The conclusion of the 3.9 merge window by bergwolf Parent article: The conclusion of the 3.9 merge window
And what about Bcache? I haven't seen news where this is aiming to, but according to its git-repo it seems to get development.
http://bcache.evilpiepirate.org/
>Bcache is a Linux kernel block layer cache. It allows one or more fast disk drives such as flash-based solid state drives (SSDs) to act as a cache for one or more slower hard disk drives.
(Log in to post comments)
The conclusion of the 3.9 merge window Posted Mar 6, 2013 14:48 UTC (Wed) by Tobu (subscriber, #24111) [Link] It seems to be the fastest of the lot, and an earlier version is in use at Google. Currently the maintainer is spoon-feeding some BIO and AIO rework through maintainer reviews, and I have no idea how much of the supporting infrastructure is left to merge at this point. It's not terribly user-friendly at the moment: no dm target that would allow in-place migration, and you have to stick to a maintainer tree for continued data access (even though a pass-through shim would be sufficient for non-writeback uses).
The conclusion of the 3.9 merge window Posted Mar 7, 2013 8:05 UTC (Thu) by ebirdie (subscriber, #512) [Link]
Thank you for the insightfull view. I have had bookmark on Bcache and an itch to try it when circumstances allow. Now that I'm aware of dm-cache I think I'll choose ease of use over topnotch performance.
The conclusion of the 3.9 merge window Posted Mar 8, 2013 2:37 UTC (Fri) by msnitzer (subscriber, #57232) [Link]
Have you benchmarked bcache vs dm-cache vs enhanceio? If so I'd love to see what you found. We have an "all-caches" branch here:
https://github.com/jthornber/linux-2.6/tree/all-caches
But we definitely need to definitely update the bcache and enhanceio code.
Also, please note that there are some dm-cache fixes that will likely be sent to Linus for 3.9-rc2 that Alasdair (DM maintainer) has staged here: http://people.redhat.com/agk/patches/linux/editing/series...
The conclusion of the 3.9 merge window Posted Mar 8, 2013 17:30 UTC (Fri) by Lennie (subscriber, #49641) [Link]
The user unfriendliness exists to protect your data when using write-back.
It is kinda annoying, I know.
But if a normal block device would be used as a backing store there is nothing to preventing accidental use even though there might be dirty data on the cache device.
The EnhanceIO developers use some udev scripts to prevent this, I haven't looked at how they do it. I guess that could work, the EnhanceIO developers said they haven't seen any problems yet. But I can definitely see why the bcache developer made his choice.
If a cachesystem would have be integrated in the filesystem the filesystem could have something recorded which would prevent it from being mounted without the user forcing it in some way when the cache device is never coming back.
It is kinda interesting to see there are 6 ways/ideas floating around to do caching or caching related things now for the Linux kernel:
The dm-cache, EnhanceIO and bcache have 'spoken' on the mailinglist and one even mentioned he didn't see any problem in having several implementations in the mainline kernel.
I'm not so sure Linus would even accept those patches. :-)
It is interesting and maybe sometimes seems a bit painful to see that many different efforts. They obviously all have their strengths and weaknesses of course.
The conclusion of the 3.9 merge window Posted Mar 8, 2013 17:49 UTC (Fri) by Lennie (subscriber, #49641) [Link]
Had a quick look at dm-cache seems they actually have 3 things which can all be stored on different devices: the backing store, the cache and the meta data.
|
|||||||||||||