dm-cache: new caching method that operates within the Linux kernel(github.com)
github.com
dm-cache: new caching method that operates within the Linux kernel
https://github.com/mingzhao/dm-cache
7 comments
Yes, dm-cache is not new, but it just had a major new release. It now has a feature to allow many vms to share one cache.
I can't speak for the flashcache team, but I do know that one goal of the dm-cache team is to get it into the upstream for the linux kernel(I know this b/c I worked with dm-cache team last year).
I can't speak for the flashcache team, but I do know that one goal of the dm-cache team is to get it into the upstream for the linux kernel(I know this b/c I worked with dm-cache team last year).
That's great to know! Hopefully one of these projects will make it into the kernel soon, since this is obviously a very useful feature.
Not to spam, but hopefully this information is useful for some HN'ers. Our startup, http://velobit.com, provides caching as well.
Alas, it is not open source, but it does have some differentiators over bcache/dm-cache. The primary pro's of those two are that they are FOSS.
Major downsides are they they are kernel patches. DM-Cache is a little more difficult as well, in the sense that it is in the DM layer, so you're creating a new device when you apply caching. Contrast with our startup, where we insert ourselves directly into the existing devices (so no need to modify fstab, etc..). Of course, I like to think we have other major differentiators as well, but I won't go on and on about them here..
That being said, this caching (especially SSD-as-caching) space is huge right now, even though it doesn't get much attention in the hot-tech startup world.
Alas, it is not open source, but it does have some differentiators over bcache/dm-cache. The primary pro's of those two are that they are FOSS.
Major downsides are they they are kernel patches. DM-Cache is a little more difficult as well, in the sense that it is in the DM layer, so you're creating a new device when you apply caching. Contrast with our startup, where we insert ourselves directly into the existing devices (so no need to modify fstab, etc..). Of course, I like to think we have other major differentiators as well, but I won't go on and on about them here..
That being said, this caching (especially SSD-as-caching) space is huge right now, even though it doesn't get much attention in the hot-tech startup world.
There's also hot tracking RFC patches floating around for the VFS layer. bcache seems quiet nice, there are block layer refactorings going on right now in order to get it merged.
I think bcache is supposed to be much faster than dm-cache. http://bcache.evilpiepirate.org/
bcache is specifically for using an SSD to cache something with much higher latency, usually a hard drive (or RAID array), but possibly also a network block device. Because of that, bcache is tuned to take advantage of the strengths of current SSDs, and to avoid write patterns that lead to excessive wear of the SSD, and to distinguish between random accesses (where SSDs excel) and sequential (where a RAID5 might be faster). This makes bcache better than the more generic dm-cache for the right workload, but it also means bcache is more complex - at best, it is months away from making it in to the staging area.
Also worth looking at: hot-data tracking in the VFS layer.
http://www.phoronix.com/scan.php?page=news_item&px=MTIwM...
Should help btrfs catch up with ZFS.
Should help btrfs catch up with ZFS.
Solaris has had this for years now with the L2ARC. I'm glad it is finally coming to Linux. Now when is Linux going to get a better page eviction algorithm, like ARC?
https://lwn.net/Articles/211246/
dm-cache is the project Facebook's flashcache is based on.
https://github.com/facebook/flashcache
I'm not sure if there's ongoing work to merge dm-cache or flashcache into the upstream linux kernel. With bcache there is.
http://www.redhat.com/archives/dm-devel/2012-July/msg00155.h...