On Mon, 01 May 2017 22:13:59 +0100 Nix <nix@xxxxxxxxxxxxx> wrote: > > (having to fiddle with "echo > /sys/..." and "cat /sys/..." is not the state > > of something you'd call a finished product). > > You mean, like md? :) You must be kidding. On the contrary I was looking to present md as the example of how it should be done, with its all-encompassing and extremely capable 'mdadm' tool -- and a complete lack of a similar tool for bcache. > I'd be more worried about the complexity required to just figure out the > space needed for half a dozen sets of lvmcache metadata and cache > filesystems. Metadata can be implicitly created and auto-managed in recent lvm versions http://fibrevillage.com/storage/460-how-to-create-lvm-cache-logical-volume ("Automatic pool metadata LV"). If not, the rule of thumb suggested everywhere is 1/1000 of the cache volume size; I doubled that just in case, and looks like I didn't have to, as my metadata partitions are only about 9.5% full each. As for half a dozen sets, I'd reconsider the need for those, as well as the entire fast/slow HDD tracks separation, just SSD-cache everything and let it figure out to not cache streaming writes on your video transcodes, or even bulk writes during your compile tests (while still caching the filesystem metadata). However the world of pain begins if you want to have multiple guest VMs each with its disk as a separate LV. One solution (that doesn't sound too clean but perhaps could work), is stacked LVM, i.e. a PV of a different volume group made on top of a cached LV. -- With respect, Roman -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
