Re: ont out of 6 bcache devices does not register automatically

[Stefan Priebe - Profihost AG <s.priebe@profihost.ag>]

Am 28.11.2017 um 21:05 schrieb Michael Lyle:
> 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@profihost.ag> 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.

I dont want to allow to register for ambiguity in general - but in case
there is ambiguity with an FS (xfs,btrfs, ...). I can't see a way where
this could be a problem. Even considering other block drivers like md or dm.

Stefan

> 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
>