Device mapper and Bcache
Kent Overstreet discussed the Bcache project, which creates an SSD-based cache for other (slower) block devices. He began by pointing out that the device mapper
(DM) stores much of the information that Bcache would need in user space. Basically, the level of pain required to extract the necessary information from DM meant that they bypassed it entirely.
It was more or less acknowledged that, because Bcache is sufficiently well established in terms of performance, that may imply that DM should provide an API it can use. Basically, if a flash cache is to be implemented in kernel, basing it upon Bcache would
be preferable. It would also be preferred if any such cache was configured via an established interface such as DM; this is the core issue that is often bashed around.
It was pointed out that Bcache also required some block-layer changes to split BIOs in some cases, depending on the contents of the btree, which would have been difficult to communicate via DM. This reinforces the original point that adapting Bcache to DM would
require a larger number of changes than expected. There was some confusion on exactly how Bcache was implemented and what the requirements are but the Bcache developers were not against adding DM support as such. They were just indifferent to DM because their
needs were already been served.
In different variations, the point was made that the community is behind the curve in terms of caching on flash and that some sort of decision is needed. This did not prevent the discussion being pulled in numerous different directions that brought up a large
number of potential issues with any possible approach. The semi-conclusion was the community "has to do something" but what that was reached no real conclusion. There was a vague message that a generic caching storage layer was required that would be based
on SSD initially but exactly at which layer this should exist as was unclear.
http://lwn.net/Articles/490501/
http://blog.csdn.net/zwcq82/article/details/7521390