Dan Williams wrote:

The consensus from LSF was that bcache need not invent a new interface
when md and dm can both do the job.  As mentioned in patch 7 this series
aims to be a minimal conversion.  Other refactoring items like
deprecating register_lock for mddev->reconfig_mutex are deferred.

This supports assembly of an already established cache array:

mdadm -A /dev/md/bcache /dev/sd[ab]

...will create the /dev/md/bcache container and a subarray representing
the cache volume.  "Flash-only", or backing-device only volumes were not
tested.  "Create" support and hot-add/hot-remove come later.

Note:
* When attempting to test with small loopback devices (100MB), assembly
  soft locks in bcache_journal_read().  That hang went away with larger
  devices, so there seems to be minimum component device size that needs
  to be considered in the tooling.

Is there any plan to separate the on-disk layout (per-device headers, etc) 
from the logic for the purpose of reuse? I can think of at least one case 
where this would be extremely useful: integration in BtrFS.

BtrFS already has its own methods for making sure a group of devices are all 
present when the filesystem is mounted, so it doesn't really need the 
formatting of the backing device bcache does to prevent it from being 
mounted solo. Putting bcache under BtrFS would be silly in the same way as 
putting it under a raid array, but bcache can't be put on top of BtrFS.

Logically, in looking at BtrFS' architecture, a cache would likely fit best 
at the 'block group' level, which IIUC would be roughly equivalent to the 
recommended 'over raid, under lvm' method of using bcache.