The conclusion of the 3.9 merge window [LWN.net]

The conclusion of the 3.9 merge window

Posted Mar 6, 2013 6:03 UTC (Wed) by bergwolf (guest, #55931)
Parent article: The conclusion of the 3.9 merge window

> The device manager has gained support for a new "dm-cache" target that is able to use a fast drive (like a solid-state device) as a cache in front of slower storage devices.

What about the EnhanceIO driver that is aiming at 3.10 merge window? I assume that they are similar code accomplishing similar job, no?

http://lwn.net/Articles/538435/

to post comments

The conclusion of the 3.9 merge window

Posted Mar 6, 2013 12:33 UTC (Wed) by Tobu (subscriber, #24111) [Link] (1 responses)

I think "dm-cache" is more similar to "dm-cache", first posted to LKML in 2006. Both are dm targets with pluggable tiering policies. EnhanceIO has some older dm-cache code by way of Flashcache, but it doesn't have the pluggable policies (I don't know if Flashcache slashed it or if there was some convergent evolution later).

The conclusion of the 3.9 merge window

Posted Mar 8, 2013 2:27 UTC (Fri) by msnitzer (subscriber, #57232) [Link]

dm-cache has no relation to the original dm-cache (or flashcache).

The conclusion of the 3.9 merge window

Posted Mar 6, 2013 13:48 UTC (Wed) by ebirdie (guest, #512) [Link] (5 responses)

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/
https://lwn.net/Articles/501632/

>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.

The conclusion of the 3.9 merge window

Posted Mar 6, 2013 14:48 UTC (Wed) by Tobu (subscriber, #24111) [Link] (4 responses)

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 (guest, #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] (1 responses)

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:
- dm-cache, now in the kernel I guess
- Facebook Flashcache
- Google bcache
- EnhanceIO was based on Flashcache I believe
- If I'm not mistake in recent kernels there is code in the VFS which keeps track of which data is hot
- btrfs developers are looking at doing something in btrfs, if I remember correctly they have expressed some interest in the VFS solution

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.