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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
