On 11/28/2017 11:59 AM, Stefan Priebe - Profihost AG wrote: > ) > > Am 28.11.2017 um 20:51 schrieb Michael Lyle: >> On Tue, Nov 28, 2017 at 11:32 AM, Stefan Priebe - Profihost AG >> <s.priebe@xxxxxxxxxxxx> wrote: >>> nobody asked for this - but bcache provides bcache-tools and upstream >>> udev rules and those don't work in this case. To i consider this an >>> upstream bug. Not a bug in my envorinment or in my distribution. >> >> I do not maintain bcache-tools. It looks like g2p wrote a set of >> rules in 2014 that Debian uses. Gentoo uses a different set of rules. >> Arch uses a slightly different set of rules. >> >> Nor is what you're trying to do completely safe, because depending on >> rule ordering it can mean if you stack md & bcache, for instance, very >> bad things could happen with your change. > > Thanks - that helped. - didn't know that the original bcache-tools which > came from kent were handed over to somebody else / or that each > distribution uses it's own. No problem. Just to put a finer point on it: Right now the current script does the safe thing when there's ambiguity and refuses to do anything. Even if I maintained bcache-tools, I couldn't really fix this. If there is a desire to proceed through ambiguity, the ordering that actions are attempted in-- RAID, filesystems, bcache, DM, etc, becomes important, and can't be solved in any one package. It's unfortunate that data can prevent the cache from registering, but it'd be much worse to register the cache in the wrong order compared to another block layer. Mike -- 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
