On 11/28/2017 11:59 AM, Stefan Priebe - Profihost AG wrote:

)

Am 28.11.2017 um 20:51 schrieb Michael Lyle:

quoted

On Tue, Nov 28, 2017 at 11:32 AM, Stefan Priebe - Profihost AG
[off-list ref] wrote:

quoted

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