>Scenario >- md attached to cacheset1 and working (on node 1) >- md detached from cacheset1 You can't just detach, you must flush everything out of cacheset1 and destroy/revoke/disassemble the relationship between the cache and MD. 'destroy-bcache(8) or make-bcache -D' if you will. Not that such a tool exists AFAIK. >- md stopped on node 1 >- md started on node 2 >- md attached to cacheset2 on node 2 No, you don't attache it, you have to create a new relationship; ala 'make-bcache -C ...' >At this point, cacheset1 is attached to nothing, but still has valid blocks >"linked" to the backing md device If you do, your data is hopelessly gone. The only way you can bounce a bcache device from one node to the other is the ENTIRE stack moves back and forth. So the SSDs have to be in the shared JBOD. And you can skip all the malarky of attach/detach. You can write udev-rules to mask/ignore certain devices so that each node only knows about it's own devices and when it's time to cross-mount the peer's, you register them with the receiving system, do the 'probe-bcache' and resume operations. That's assuming the writes the client sent to the original node really got committed (write-thru not withstanding). -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
