Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

The conclusion of the 3.9 merge window

Posted Mar 6, 2013 14:48 UTC (Wed) by Tobu (subscriber, #24111)
In reply to: The conclusion of the 3.9 merge window by ebirdie
Parent article: The conclusion of the 3.9 merge window

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

(Log in to post comments)

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