The conclusion of the 3.9 merge window

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.