ont out of 6 bcache devices does not register automatically

ont out of 6 bcache devices does not register automatically

[Stefan Priebe - Profihost AG]

Hello,

i've 6 bcache blk devices attached to 3 caching ssds (2 each). One fails
to register automatically at boot time.

After reboot i always need to execute:
echo /dev/sdf1 >/sys/fs/bcache/register

to bring up the bcache device.

Any idea?

Greets,
Stefan

Register happens through the following udev file:
# register bcache devices as they come up
# man 7 udev for syntax

SUBSYSTEM!="block", GOTO="bcache_end"
ACTION=="remove", GOTO="bcache_end"

# blkid was run by the standard udev rules
# It recognised bcache (util-linux 2.24+)
ENV{ID_FS_TYPE}=="bcache", GOTO="bcache_backing_found"
# It recognised something else; bail
ENV{ID_FS_TYPE}=="?*", GOTO="bcache_backing_end"

# Backing devices: scan, symlink, register
IMPORT{program}="probe-bcache -o udev $tempnode"
ENV{ID_FS_TYPE}!="bcache", GOTO="bcache_backing_end"
ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"

LABEL="bcache_backing_found"
RUN+="bcache-register $tempnode"
LABEL="bcache_backing_end"

# Cached devices: symlink
DRIVER=="bcache", ENV{CACHED_UUID}=="?*", \
        SYMLINK+="bcache/by-uuid/$env{CACHED_UUID}"
DRIVER=="bcache", ENV{CACHED_LABEL}=="?*", \
        SYMLINK+="bcache/by-label/$env{CACHED_LABEL}"

LABEL="bcache_end"

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

[Coly Li]

On 22/11/2017 7:23 PM, Stefan Priebe - Profihost AG wrote:
> Hello,
> 
> i've 6 bcache blk devices attached to 3 caching ssds (2 each). One fails
> to register automatically at boot time.
> 
> After reboot i always need to execute:
> echo /dev/sdf1 >/sys/fs/bcache/register
> 
> to bring up the bcache device.
> 
> Any idea?

Hi Stefan,

Is there any clue from kernel message ?

Thanks.

Coly Li

> Register happens through the following udev file:
> # register bcache devices as they come up
> # man 7 udev for syntax
> 
> SUBSYSTEM!="block", GOTO="bcache_end"
> ACTION=="remove", GOTO="bcache_end"
> 
> # blkid was run by the standard udev rules
> # It recognised bcache (util-linux 2.24+)
> ENV{ID_FS_TYPE}=="bcache", GOTO="bcache_backing_found"
> # It recognised something else; bail
> ENV{ID_FS_TYPE}=="?*", GOTO="bcache_backing_end"
> 
> # Backing devices: scan, symlink, register
> IMPORT{program}="probe-bcache -o udev $tempnode"
> ENV{ID_FS_TYPE}!="bcache", GOTO="bcache_backing_end"
> ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
> 
> LABEL="bcache_backing_found"
> RUN+="bcache-register $tempnode"
> LABEL="bcache_backing_end"
> 
> # Cached devices: symlink
> DRIVER=="bcache", ENV{CACHED_UUID}=="?*", \
>         SYMLINK+="bcache/by-uuid/$env{CACHED_UUID}"
> DRIVER=="bcache", ENV{CACHED_LABEL}=="?*", \
>         SYMLINK+="bcache/by-label/$env{CACHED_LABEL}"
> 
> LABEL="bcache_end"
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Coly Li

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

[Stefan Priebe - Profihost AG]

Am 22.11.2017 um 13:16 schrieb Coly Li:
> On 22/11/2017 7:23 PM, Stefan Priebe - Profihost AG wrote:
>> Hello,
>>
>> i've 6 bcache blk devices attached to 3 caching ssds (2 each). One fails
>> to register automatically at boot time.
>>
>> After reboot i always need to execute:
>> echo /dev/sdf1 >/sys/fs/bcache/register
>>
>> to bring up the bcache device.
>>
>> Any idea?
> 
> Hi Stefan,
> 
> Is there any clue from kernel message ?

Sadly not.

Working one:
]# dmesg | grep sdi
[    1.060377] sd 5:0:0:0: [sdi] 1953525168 512-byte logical blocks:
(1.00 TB/932 GiB)
[    1.060393] sd 5:0:0:0: [sdi] Write Protect is off
[    1.060396] sd 5:0:0:0: [sdi] Mode Sense: 00 3a 00 00
[    1.060425] sd 5:0:0:0: [sdi] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[    1.104341]  sdi: sdi1
[    1.104644] sd 5:0:0:0: [sdi] Attached SCSI disk
[    2.005452] bcache: register_bdev() registered backing device sdi1
[    2.045211] bcache: bch_cached_dev_attach() Caching sdi1 as bcache0
on set 76b95bf8-9cc7-407f-9f9e-a42b6d1bcb27


not working one:
# dmesg | grep sdf
[    0.946107] sd 0:0:5:0: [sdf] 1953525168 512-byte logical blocks:
(1.00 TB/932 GiB)
[    1.400267] sd 0:0:5:0: [sdf] Write Protect is off
[    1.400267] sd 0:0:5:0: [sdf] Mode Sense: 00 00 00 00
[    1.401347] sd 0:0:5:0: [sdf] Write cache: enabled, read cache:
enabled, supports DPO and FUA
[    1.902910]  sdf: sdf1
[    2.341289] sd 0:0:5:0: [sdf] Attached SCSI disk
[  295.458804] bcache: register_bdev() registered backing device sdf1
[  295.506656] bcache: bch_cached_dev_attach() Caching sdf1 as bcache5
on set 76b95bf8-9cc7-407f-9f9e-a42b6d1bcb27

At 295s i registeeed it manually.

Greets,
Stefan

> 
> Thanks.
> 
> Coly Li
> 
>> Register happens through the following udev file:
>> # register bcache devices as they come up
>> # man 7 udev for syntax
>>
>> SUBSYSTEM!="block", GOTO="bcache_end"
>> ACTION=="remove", GOTO="bcache_end"
>>
>> # blkid was run by the standard udev rules
>> # It recognised bcache (util-linux 2.24+)
>> ENV{ID_FS_TYPE}=="bcache", GOTO="bcache_backing_found"
>> # It recognised something else; bail
>> ENV{ID_FS_TYPE}=="?*", GOTO="bcache_backing_end"
>>
>> # Backing devices: scan, symlink, register
>> IMPORT{program}="probe-bcache -o udev $tempnode"
>> ENV{ID_FS_TYPE}!="bcache", GOTO="bcache_backing_end"
>> ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
>>
>> LABEL="bcache_backing_found"
>> RUN+="bcache-register $tempnode"
>> LABEL="bcache_backing_end"
>>
>> # Cached devices: symlink
>> DRIVER=="bcache", ENV{CACHED_UUID}=="?*", \
>>         SYMLINK+="bcache/by-uuid/$env{CACHED_UUID}"
>> DRIVER=="bcache", ENV{CACHED_LABEL}=="?*", \
>>         SYMLINK+="bcache/by-label/$env{CACHED_LABEL}"
>>
>> LABEL="bcache_end"
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> 

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

[Coly Li]

On 22/11/2017 8:26 PM, Stefan Priebe - Profihost AG wrote:
> 
> Am 22.11.2017 um 13:16 schrieb Coly Li:
>> On 22/11/2017 7:23 PM, Stefan Priebe - Profihost AG wrote:
>>> Hello,
>>>
>>> i've 6 bcache blk devices attached to 3 caching ssds (2 each). One fails
>>> to register automatically at boot time.
>>>
>>> After reboot i always need to execute:
>>> echo /dev/sdf1 >/sys/fs/bcache/register
>>>
>>> to bring up the bcache device.
>>>
>>> Any idea?
>>
>> Hi Stefan,
>>
>> Is there any clue from kernel message ?
> 
> Sadly not.
> 
> Working one:
> ]# dmesg | grep sdi
> [    1.060377] sd 5:0:0:0: [sdi] 1953525168 512-byte logical blocks:
> (1.00 TB/932 GiB)
> [    1.060393] sd 5:0:0:0: [sdi] Write Protect is off
> [    1.060396] sd 5:0:0:0: [sdi] Mode Sense: 00 3a 00 00
> [    1.060425] sd 5:0:0:0: [sdi] Write cache: enabled, read cache:
> enabled, doesn't support DPO or FUA
> [    1.104341]  sdi: sdi1
> [    1.104644] sd 5:0:0:0: [sdi] Attached SCSI disk
> [    2.005452] bcache: register_bdev() registered backing device sdi1
> [    2.045211] bcache: bch_cached_dev_attach() Caching sdi1 as bcache0
> on set 76b95bf8-9cc7-407f-9f9e-a42b6d1bcb27
> 
> 
> not working one:
> # dmesg | grep sdf
> [    0.946107] sd 0:0:5:0: [sdf] 1953525168 512-byte logical blocks:
> (1.00 TB/932 GiB)
> [    1.400267] sd 0:0:5:0: [sdf] Write Protect is off
> [    1.400267] sd 0:0:5:0: [sdf] Mode Sense: 00 00 00 00
> [    1.401347] sd 0:0:5:0: [sdf] Write cache: enabled, read cache:
> enabled, supports DPO and FUA
> [    1.902910]  sdf: sdf1
> [    2.341289] sd 0:0:5:0: [sdf] Attached SCSI disk
> [  295.458804] bcache: register_bdev() registered backing device sdf1
> [  295.506656] bcache: bch_cached_dev_attach() Caching sdf1 as bcache5
> on set 76b95bf8-9cc7-407f-9f9e-a42b6d1bcb27
> 
> At 295s i registeeed it manually.

Hi Stefan,

Hmm, I don't have idea here. Anyway, is the cache mode set as writeback?
Recently I post a patch to fix a potential deadlock between writeback
rate update kworker and register code, I am not sure whether it is
relative to your issue, but at least we can have a try. the patch title is:
 [RFC] bcache: fix a circular dead locking with dc->writeback_lock and
bch_register_lock

Just for your information.

Coly Li


>>> Register happens through the following udev file:
>>> # register bcache devices as they come up
>>> # man 7 udev for syntax
>>>
>>> SUBSYSTEM!="block", GOTO="bcache_end"
>>> ACTION=="remove", GOTO="bcache_end"
>>>
>>> # blkid was run by the standard udev rules
>>> # It recognised bcache (util-linux 2.24+)
>>> ENV{ID_FS_TYPE}=="bcache", GOTO="bcache_backing_found"
>>> # It recognised something else; bail
>>> ENV{ID_FS_TYPE}=="?*", GOTO="bcache_backing_end"
>>>
>>> # Backing devices: scan, symlink, register
>>> IMPORT{program}="probe-bcache -o udev $tempnode"
>>> ENV{ID_FS_TYPE}!="bcache", GOTO="bcache_backing_end"
>>> ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
>>>
>>> LABEL="bcache_backing_found"
>>> RUN+="bcache-register $tempnode"
>>> LABEL="bcache_backing_end"
>>>
>>> # Cached devices: symlink
>>> DRIVER=="bcache", ENV{CACHED_UUID}=="?*", \
>>>         SYMLINK+="bcache/by-uuid/$env{CACHED_UUID}"
>>> DRIVER=="bcache", ENV{CACHED_LABEL}=="?*", \
>>>         SYMLINK+="bcache/by-label/$env{CACHED_LABEL}"
>>>
>>> LABEL="bcache_end"
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>>


-- 
Coly Li

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

[Stefan Priebe - Profihost AG]

Am 22.11.2017 um 13:57 schrieb Coly Li:
> On 22/11/2017 8:26 PM, Stefan Priebe - Profihost AG wrote:
>>
>> Am 22.11.2017 um 13:16 schrieb Coly Li:
>>> On 22/11/2017 7:23 PM, Stefan Priebe - Profihost AG wrote:
>>>> Hello,
>>>>
>>>> i've 6 bcache blk devices attached to 3 caching ssds (2 each). One fails
>>>> to register automatically at boot time.
>>>>
>>>> After reboot i always need to execute:
>>>> echo /dev/sdf1 >/sys/fs/bcache/register
>>>>
>>>> to bring up the bcache device.
>>>>
>>>> Any idea?
>>>
>>> Hi Stefan,
>>>
>>> Is there any clue from kernel message ?
>>
>> Sadly not.
>>
>> Working one:
>> ]# dmesg | grep sdi
>> [    1.060377] sd 5:0:0:0: [sdi] 1953525168 512-byte logical blocks:
>> (1.00 TB/932 GiB)
>> [    1.060393] sd 5:0:0:0: [sdi] Write Protect is off
>> [    1.060396] sd 5:0:0:0: [sdi] Mode Sense: 00 3a 00 00
>> [    1.060425] sd 5:0:0:0: [sdi] Write cache: enabled, read cache:
>> enabled, doesn't support DPO or FUA
>> [    1.104341]  sdi: sdi1
>> [    1.104644] sd 5:0:0:0: [sdi] Attached SCSI disk
>> [    2.005452] bcache: register_bdev() registered backing device sdi1
>> [    2.045211] bcache: bch_cached_dev_attach() Caching sdi1 as bcache0
>> on set 76b95bf8-9cc7-407f-9f9e-a42b6d1bcb27
>>
>>
>> not working one:
>> # dmesg | grep sdf
>> [    0.946107] sd 0:0:5:0: [sdf] 1953525168 512-byte logical blocks:
>> (1.00 TB/932 GiB)
>> [    1.400267] sd 0:0:5:0: [sdf] Write Protect is off
>> [    1.400267] sd 0:0:5:0: [sdf] Mode Sense: 00 00 00 00
>> [    1.401347] sd 0:0:5:0: [sdf] Write cache: enabled, read cache:
>> enabled, supports DPO and FUA
>> [    1.902910]  sdf: sdf1
>> [    2.341289] sd 0:0:5:0: [sdf] Attached SCSI disk
>> [  295.458804] bcache: register_bdev() registered backing device sdf1
>> [  295.506656] bcache: bch_cached_dev_attach() Caching sdf1 as bcache5
>> on set 76b95bf8-9cc7-407f-9f9e-a42b6d1bcb27
>>
>> At 295s i registeeed it manually.
> 
> Hi Stefan,
> 
> Hmm, I don't have idea here. Anyway, is the cache mode set as writeback?
> Recently I post a patch to fix a potential deadlock between writeback
> rate update kworker and register code, I am not sure whether it is
> relative to your issue, but at least we can have a try. the patch title is:
>  [RFC] bcache: fix a circular dead locking with dc->writeback_lock and
> bch_register_lock
> 
> Just for your information.

i can try that one - can you please resend? I can't find that mail and
don't know how to grab that one our of the web html archives to apply
correctly.

Stefan

> 
> Coly Li
> 
> 
>>>> Register happens through the following udev file:
>>>> # register bcache devices as they come up
>>>> # man 7 udev for syntax
>>>>
>>>> SUBSYSTEM!="block", GOTO="bcache_end"
>>>> ACTION=="remove", GOTO="bcache_end"
>>>>
>>>> # blkid was run by the standard udev rules
>>>> # It recognised bcache (util-linux 2.24+)
>>>> ENV{ID_FS_TYPE}=="bcache", GOTO="bcache_backing_found"
>>>> # It recognised something else; bail
>>>> ENV{ID_FS_TYPE}=="?*", GOTO="bcache_backing_end"
>>>>
>>>> # Backing devices: scan, symlink, register
>>>> IMPORT{program}="probe-bcache -o udev $tempnode"
>>>> ENV{ID_FS_TYPE}!="bcache", GOTO="bcache_backing_end"
>>>> ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
>>>>
>>>> LABEL="bcache_backing_found"
>>>> RUN+="bcache-register $tempnode"
>>>> LABEL="bcache_backing_end"
>>>>
>>>> # Cached devices: symlink
>>>> DRIVER=="bcache", ENV{CACHED_UUID}=="?*", \
>>>>         SYMLINK+="bcache/by-uuid/$env{CACHED_UUID}"
>>>> DRIVER=="bcache", ENV{CACHED_LABEL}=="?*", \
>>>>         SYMLINK+="bcache/by-label/$env{CACHED_LABEL}"
>>>>
>>>> LABEL="bcache_end"
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>>
> 
> 

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

[Coly Li]

On 22/11/2017 9:14 PM, Stefan Priebe - Profihost AG wrote:
> Am 22.11.2017 um 13:57 schrieb Coly Li:
>> On 22/11/2017 8:26 PM, Stefan Priebe - Profihost AG wrote:
>>>
>>> Am 22.11.2017 um 13:16 schrieb Coly Li:
>>>> On 22/11/2017 7:23 PM, Stefan Priebe - Profihost AG wrote:
>>>>> Hello,
>>>>>
>>>>> i've 6 bcache blk devices attached to 3 caching ssds (2 each). One fails
>>>>> to register automatically at boot time.
>>>>>
>>>>> After reboot i always need to execute:
>>>>> echo /dev/sdf1 >/sys/fs/bcache/register
>>>>>
>>>>> to bring up the bcache device.
>>>>>
>>>>> Any idea?
>>>>
>>>> Hi Stefan,
>>>>
>>>> Is there any clue from kernel message ?
>>>
>>> Sadly not.
>>>
>>> Working one:
>>> ]# dmesg | grep sdi
>>> [    1.060377] sd 5:0:0:0: [sdi] 1953525168 512-byte logical blocks:
>>> (1.00 TB/932 GiB)
>>> [    1.060393] sd 5:0:0:0: [sdi] Write Protect is off
>>> [    1.060396] sd 5:0:0:0: [sdi] Mode Sense: 00 3a 00 00
>>> [    1.060425] sd 5:0:0:0: [sdi] Write cache: enabled, read cache:
>>> enabled, doesn't support DPO or FUA
>>> [    1.104341]  sdi: sdi1
>>> [    1.104644] sd 5:0:0:0: [sdi] Attached SCSI disk
>>> [    2.005452] bcache: register_bdev() registered backing device sdi1
>>> [    2.045211] bcache: bch_cached_dev_attach() Caching sdi1 as bcache0
>>> on set 76b95bf8-9cc7-407f-9f9e-a42b6d1bcb27
>>>
>>>
>>> not working one:
>>> # dmesg | grep sdf
>>> [    0.946107] sd 0:0:5:0: [sdf] 1953525168 512-byte logical blocks:
>>> (1.00 TB/932 GiB)
>>> [    1.400267] sd 0:0:5:0: [sdf] Write Protect is off
>>> [    1.400267] sd 0:0:5:0: [sdf] Mode Sense: 00 00 00 00
>>> [    1.401347] sd 0:0:5:0: [sdf] Write cache: enabled, read cache:
>>> enabled, supports DPO and FUA
>>> [    1.902910]  sdf: sdf1
>>> [    2.341289] sd 0:0:5:0: [sdf] Attached SCSI disk
>>> [  295.458804] bcache: register_bdev() registered backing device sdf1
>>> [  295.506656] bcache: bch_cached_dev_attach() Caching sdf1 as bcache5
>>> on set 76b95bf8-9cc7-407f-9f9e-a42b6d1bcb27
>>>
>>> At 295s i registeeed it manually.
>>
>> Hi Stefan,
>>
>> Hmm, I don't have idea here. Anyway, is the cache mode set as writeback?
>> Recently I post a patch to fix a potential deadlock between writeback
>> rate update kworker and register code, I am not sure whether it is
>> relative to your issue, but at least we can have a try. the patch title is:
>>  [RFC] bcache: fix a circular dead locking with dc->writeback_lock and
>> bch_register_lock
>>
>> Just for your information.
> 
> i can try that one - can you please resend? I can't find that mail and
> don't know how to grab that one our of the web html archives to apply
> correctly.

Hi Stefan,

Can you download the patch from following URL:
https://git.kernel.org/pub/scm/linux/kernel/git/colyli/bcache-patches.git/plain/for-test/0001-bcache-fix-a-circular-dead-locking-with-dc-writeback.patch

Coly Li

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

[Stefan Priebe - Profihost AG]

Hi Coly,
Am 22.11.2017 um 14:29 schrieb Coly Li:
> On 22/11/2017 9:14 PM, Stefan Priebe - Profihost AG wrote:
>> Am 22.11.2017 um 13:57 schrieb Coly Li:
>>> On 22/11/2017 8:26 PM, Stefan Priebe - Profihost AG wrote:
>>>>
>>>> Am 22.11.2017 um 13:16 schrieb Coly Li:
>>>>> On 22/11/2017 7:23 PM, Stefan Priebe - Profihost AG wrote:
>>>>>> Hello,
>>>>>>
>>>>>> i've 6 bcache blk devices attached to 3 caching ssds (2 each). One fails
>>>>>> to register automatically at boot time.
>>>>>>
>>>>>> After reboot i always need to execute:
>>>>>> echo /dev/sdf1 >/sys/fs/bcache/register
>>>>>>
>>>>>> to bring up the bcache device.
>>>>>>
>>>>>> Any idea?
>>>>>
>>>>> Hi Stefan,
>>>>>
>>>>> Is there any clue from kernel message ?
>>>>
>>>> Sadly not.
>>>>
>>>> Working one:
>>>> ]# dmesg | grep sdi
>>>> [    1.060377] sd 5:0:0:0: [sdi] 1953525168 512-byte logical blocks:
>>>> (1.00 TB/932 GiB)
>>>> [    1.060393] sd 5:0:0:0: [sdi] Write Protect is off
>>>> [    1.060396] sd 5:0:0:0: [sdi] Mode Sense: 00 3a 00 00
>>>> [    1.060425] sd 5:0:0:0: [sdi] Write cache: enabled, read cache:
>>>> enabled, doesn't support DPO or FUA
>>>> [    1.104341]  sdi: sdi1
>>>> [    1.104644] sd 5:0:0:0: [sdi] Attached SCSI disk
>>>> [    2.005452] bcache: register_bdev() registered backing device sdi1
>>>> [    2.045211] bcache: bch_cached_dev_attach() Caching sdi1 as bcache0
>>>> on set 76b95bf8-9cc7-407f-9f9e-a42b6d1bcb27
>>>>
>>>>
>>>> not working one:
>>>> # dmesg | grep sdf
>>>> [    0.946107] sd 0:0:5:0: [sdf] 1953525168 512-byte logical blocks:
>>>> (1.00 TB/932 GiB)
>>>> [    1.400267] sd 0:0:5:0: [sdf] Write Protect is off
>>>> [    1.400267] sd 0:0:5:0: [sdf] Mode Sense: 00 00 00 00
>>>> [    1.401347] sd 0:0:5:0: [sdf] Write cache: enabled, read cache:
>>>> enabled, supports DPO and FUA
>>>> [    1.902910]  sdf: sdf1
>>>> [    2.341289] sd 0:0:5:0: [sdf] Attached SCSI disk
>>>> [  295.458804] bcache: register_bdev() registered backing device sdf1
>>>> [  295.506656] bcache: bch_cached_dev_attach() Caching sdf1 as bcache5
>>>> on set 76b95bf8-9cc7-407f-9f9e-a42b6d1bcb27
>>>>
>>>> At 295s i registeeed it manually.
>>>
>>> Hi Stefan,
>>>
>>> Hmm, I don't have idea here. Anyway, is the cache mode set as writeback?
>>> Recently I post a patch to fix a potential deadlock between writeback
>>> rate update kworker and register code, I am not sure whether it is
>>> relative to your issue, but at least we can have a try. the patch title is:
>>>  [RFC] bcache: fix a circular dead locking with dc->writeback_lock and
>>> bch_register_lock
>>>
>>> Just for your information.
>>
>> i can try that one - can you please resend? I can't find that mail and
>> don't know how to grab that one our of the web html archives to apply
>> correctly.
> 
> Hi Stefan,
> 
> Can you download the patch from following URL:
> https://git.kernel.org/pub/scm/linux/kernel/git/colyli/bcache-patches.git/plain/for-test/0001-bcache-fix-a-circular-dead-locking-with-dc-writeback.patch

thanks, sadly it does not help. More ideas? Is there an easy way to
debug the calls to probe-bcache and bcache-register from udev?

Greets,
Stefan

> Coly Li
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Coly Li]

On 22/11/2017 10:16 PM, Stefan Priebe - Profihost AG wrote:
> Hi Coly,
> Am 22.11.2017 um 14:29 schrieb Coly Li:
>> On 22/11/2017 9:14 PM, Stefan Priebe - Profihost AG wrote:
>>> Am 22.11.2017 um 13:57 schrieb Coly Li:
>>>> On 22/11/2017 8:26 PM, Stefan Priebe - Profihost AG wrote:
>>>>>
>>>>> Am 22.11.2017 um 13:16 schrieb Coly Li:
>>>>>> On 22/11/2017 7:23 PM, Stefan Priebe - Profihost AG wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> i've 6 bcache blk devices attached to 3 caching ssds (2 each). One fails
>>>>>>> to register automatically at boot time.
>>>>>>>
>>>>>>> After reboot i always need to execute:
>>>>>>> echo /dev/sdf1 >/sys/fs/bcache/register
>>>>>>>
>>>>>>> to bring up the bcache device.
>>>>>>>
>>>>>>> Any idea?
>>>>>>
>>>>>> Hi Stefan,
>>>>>>
>>>>>> Is there any clue from kernel message ?
>>>>>
>>>>> Sadly not.
>>>>>
>>>>> Working one:
>>>>> ]# dmesg | grep sdi
>>>>> [    1.060377] sd 5:0:0:0: [sdi] 1953525168 512-byte logical blocks:
>>>>> (1.00 TB/932 GiB)
>>>>> [    1.060393] sd 5:0:0:0: [sdi] Write Protect is off
>>>>> [    1.060396] sd 5:0:0:0: [sdi] Mode Sense: 00 3a 00 00
>>>>> [    1.060425] sd 5:0:0:0: [sdi] Write cache: enabled, read cache:
>>>>> enabled, doesn't support DPO or FUA
>>>>> [    1.104341]  sdi: sdi1
>>>>> [    1.104644] sd 5:0:0:0: [sdi] Attached SCSI disk
>>>>> [    2.005452] bcache: register_bdev() registered backing device sdi1
>>>>> [    2.045211] bcache: bch_cached_dev_attach() Caching sdi1 as bcache0
>>>>> on set 76b95bf8-9cc7-407f-9f9e-a42b6d1bcb27
>>>>>
>>>>>
>>>>> not working one:
>>>>> # dmesg | grep sdf
>>>>> [    0.946107] sd 0:0:5:0: [sdf] 1953525168 512-byte logical blocks:
>>>>> (1.00 TB/932 GiB)
>>>>> [    1.400267] sd 0:0:5:0: [sdf] Write Protect is off
>>>>> [    1.400267] sd 0:0:5:0: [sdf] Mode Sense: 00 00 00 00
>>>>> [    1.401347] sd 0:0:5:0: [sdf] Write cache: enabled, read cache:
>>>>> enabled, supports DPO and FUA
>>>>> [    1.902910]  sdf: sdf1
>>>>> [    2.341289] sd 0:0:5:0: [sdf] Attached SCSI disk
>>>>> [  295.458804] bcache: register_bdev() registered backing device sdf1
>>>>> [  295.506656] bcache: bch_cached_dev_attach() Caching sdf1 as bcache5
>>>>> on set 76b95bf8-9cc7-407f-9f9e-a42b6d1bcb27
>>>>>
>>>>> At 295s i registeeed it manually.
>>>>
>>>> Hi Stefan,
>>>>
>>>> Hmm, I don't have idea here. Anyway, is the cache mode set as writeback?
>>>> Recently I post a patch to fix a potential deadlock between writeback
>>>> rate update kworker and register code, I am not sure whether it is
>>>> relative to your issue, but at least we can have a try. the patch title is:
>>>>  [RFC] bcache: fix a circular dead locking with dc->writeback_lock and
>>>> bch_register_lock
>>>>
>>>> Just for your information.
>>>
>>> i can try that one - can you please resend? I can't find that mail and
>>> don't know how to grab that one our of the web html archives to apply
>>> correctly.
>>
>> Hi Stefan,
>>
>> Can you download the patch from following URL:
>> https://git.kernel.org/pub/scm/linux/kernel/git/colyli/bcache-patches.git/plain/for-test/0001-bcache-fix-a-circular-dead-locking-with-dc-writeback.patch
> 
> thanks, sadly it does not help. More ideas? Is there an easy way to
> debug the calls to probe-bcache and bcache-register from udev?

Hmm, udev is a miracle to me yet...

I guess maybe I happen to have 6 hard drives (from 120G to 2TB) as
backing device, and 3 PCIe SSDs as cache device. Can you give me a
detail configuration that how the bcache devices are configured and how
the udev rules are deployed. I can also try to reproduce on my server.

Currently the hardware is occupied by other task, I can take a try for
the registration issue if the hardware can be free next Monday.

Thanks.

Coly Li


-- 
Coly Li

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

[Stefan Priebe - Profihost AG]

Am 22.11.2017 um 16:51 schrieb Coly Li:
> On 22/11/2017 10:16 PM, Stefan Priebe - Profihost AG wrote:
>> Hi Coly,
>> Am 22.11.2017 um 14:29 schrieb Coly Li:
>>> On 22/11/2017 9:14 PM, Stefan Priebe - Profihost AG wrote:
>>>> Am 22.11.2017 um 13:57 schrieb Coly Li:
>>>>> On 22/11/2017 8:26 PM, Stefan Priebe - Profihost AG wrote:
>>>>>>
>>>>>> Am 22.11.2017 um 13:16 schrieb Coly Li:
>>>>>>> On 22/11/2017 7:23 PM, Stefan Priebe - Profihost AG wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> i've 6 bcache blk devices attached to 3 caching ssds (2 each). One fails
>>>>>>>> to register automatically at boot time.
>>>>>>>>
>>>>>>>> After reboot i always need to execute:
>>>>>>>> echo /dev/sdf1 >/sys/fs/bcache/register
>>>>>>>>
>>>>>>>> to bring up the bcache device.
>>>>>>>>
>>>>>>>> Any idea?
>>>>>>>
>>>>>>> Hi Stefan,
>>>>>>>
>>>>>>> Is there any clue from kernel message ?
>>>>>>
>>>>>> Sadly not.
>>>>>>
>>>>>> Working one:
>>>>>> ]# dmesg | grep sdi
>>>>>> [    1.060377] sd 5:0:0:0: [sdi] 1953525168 512-byte logical blocks:
>>>>>> (1.00 TB/932 GiB)
>>>>>> [    1.060393] sd 5:0:0:0: [sdi] Write Protect is off
>>>>>> [    1.060396] sd 5:0:0:0: [sdi] Mode Sense: 00 3a 00 00
>>>>>> [    1.060425] sd 5:0:0:0: [sdi] Write cache: enabled, read cache:
>>>>>> enabled, doesn't support DPO or FUA
>>>>>> [    1.104341]  sdi: sdi1
>>>>>> [    1.104644] sd 5:0:0:0: [sdi] Attached SCSI disk
>>>>>> [    2.005452] bcache: register_bdev() registered backing device sdi1
>>>>>> [    2.045211] bcache: bch_cached_dev_attach() Caching sdi1 as bcache0
>>>>>> on set 76b95bf8-9cc7-407f-9f9e-a42b6d1bcb27
>>>>>>
>>>>>>
>>>>>> not working one:
>>>>>> # dmesg | grep sdf
>>>>>> [    0.946107] sd 0:0:5:0: [sdf] 1953525168 512-byte logical blocks:
>>>>>> (1.00 TB/932 GiB)
>>>>>> [    1.400267] sd 0:0:5:0: [sdf] Write Protect is off
>>>>>> [    1.400267] sd 0:0:5:0: [sdf] Mode Sense: 00 00 00 00
>>>>>> [    1.401347] sd 0:0:5:0: [sdf] Write cache: enabled, read cache:
>>>>>> enabled, supports DPO and FUA
>>>>>> [    1.902910]  sdf: sdf1
>>>>>> [    2.341289] sd 0:0:5:0: [sdf] Attached SCSI disk
>>>>>> [  295.458804] bcache: register_bdev() registered backing device sdf1
>>>>>> [  295.506656] bcache: bch_cached_dev_attach() Caching sdf1 as bcache5
>>>>>> on set 76b95bf8-9cc7-407f-9f9e-a42b6d1bcb27
>>>>>>
>>>>>> At 295s i registeeed it manually.
>>>>>
>>>>> Hi Stefan,
>>>>>
>>>>> Hmm, I don't have idea here. Anyway, is the cache mode set as writeback?
>>>>> Recently I post a patch to fix a potential deadlock between writeback
>>>>> rate update kworker and register code, I am not sure whether it is
>>>>> relative to your issue, but at least we can have a try. the patch title is:
>>>>>  [RFC] bcache: fix a circular dead locking with dc->writeback_lock and
>>>>> bch_register_lock
>>>>>
>>>>> Just for your information.
>>>>
>>>> i can try that one - can you please resend? I can't find that mail and
>>>> don't know how to grab that one our of the web html archives to apply
>>>> correctly.
>>>
>>> Hi Stefan,
>>>
>>> Can you download the patch from following URL:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/colyli/bcache-patches.git/plain/for-test/0001-bcache-fix-a-circular-dead-locking-with-dc-writeback.patch
>>
>> thanks, sadly it does not help. More ideas? Is there an easy way to
>> debug the calls to probe-bcache and bcache-register from udev?
> 
> Hmm, udev is a miracle to me yet...
> 
> I guess maybe I happen to have 6 hard drives (from 120G to 2TB) as
> backing device, and 3 PCIe SSDs as cache device. Can you give me a
> detail configuration that how the bcache devices are configured and how
> the udev rules are deployed. I can also try to reproduce on my server.
> 
> Currently the hardware is occupied by other task, I can take a try for
> the registration issue if the hardware can be free next Monday.

Thanks Coly but there's no need to test this. I've another bunch of
servers running at least the same amount of bcache devices without any
problems. Just this one does not register.

Stefan

> 
> Thanks.
> 
> Coly Li
> 
> 

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

[Michael Lyle]

Hi Coly, Stefan--

On 11/22/2017 05:14 AM, Stefan Priebe - Profihost AG wrote:
>> Hi Stefan,
>>
>> Hmm, I don't have idea here. Anyway, is the cache mode set as writeback?
>> Recently I post a patch to fix a potential deadlock between writeback
>> rate update kworker and register code, I am not sure whether it is
>> relative to your issue, but at least we can have a try. the patch title is:
>>  [RFC] bcache: fix a circular dead locking with dc->writeback_lock and
>> bch_register_lock
>>
>> Just for your information.
> 
> i can try that one - can you please resend? I can't find that mail and
> don't know how to grab that one our of the web html archives to apply
> correctly.
> 
> Stefan

I don't think there's any chance this patch will do anything.  If
there's a deadlock, the whole thing will become stuck forever and never
allow registration or progress on the device again-- which doesn't match
the symptoms here.

This probably relates to udev configuration in your environment somehow.

Mike

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

[Stefan Priebe - Profihost AG]

Am 22.11.2017 um 18:51 schrieb Michael Lyle:
> Hi Coly, Stefan--
> 
> On 11/22/2017 05:14 AM, Stefan Priebe - Profihost AG wrote:
>>> Hi Stefan,
>>>
>>> Hmm, I don't have idea here. Anyway, is the cache mode set as writeback?
>>> Recently I post a patch to fix a potential deadlock between writeback
>>> rate update kworker and register code, I am not sure whether it is
>>> relative to your issue, but at least we can have a try. the patch title is:
>>>  [RFC] bcache: fix a circular dead locking with dc->writeback_lock and
>>> bch_register_lock
>>>
>>> Just for your information.
>>
>> i can try that one - can you please resend? I can't find that mail and
>> don't know how to grab that one our of the web html archives to apply
>> correctly.
>>
>> Stefan
> 
> I don't think there's any chance this patch will do anything.  If
> there's a deadlock, the whole thing will become stuck forever and never
> allow registration or progress on the device again-- which doesn't match
> the symptoms here.

No it does not ;-)

> This probably relates to udev configuration in your environment somehow.

Default debian udev - nothing special. Works on 50 other systems
perfectly only one where it does not... but udev debugging just sucks.

Stefan


> Mike
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Stefan Priebe - Profihost AG]

Hi Coly,
  Hi Michael,


Am 22.11.2017 um 20:06 schrieb Stefan Priebe - Profihost AG:
> Am 22.11.2017 um 18:51 schrieb Michael Lyle:
>> Hi Coly, Stefan--
>>
>> On 11/22/2017 05:14 AM, Stefan Priebe - Profihost AG wrote:
>>>> Hi Stefan,
>>>>
>>>> Hmm, I don't have idea here. Anyway, is the cache mode set as writeback?
>>>> Recently I post a patch to fix a potential deadlock between writeback
>>>> rate update kworker and register code, I am not sure whether it is
>>>> relative to your issue, but at least we can have a try. the patch title is:
>>>>  [RFC] bcache: fix a circular dead locking with dc->writeback_lock and
>>>> bch_register_lock
>>>>
>>>> Just for your information.
>>>
>>> i can try that one - can you please resend? I can't find that mail and
>>> don't know how to grab that one our of the web html archives to apply
>>> correctly.
>>>
>>> Stefan
>>
>> I don't think there's any chance this patch will do anything.  If
>> there's a deadlock, the whole thing will become stuck forever and never
>> allow registration or progress on the device again-- which doesn't match
>> the symptoms here.
> 
> No it does not ;-)
> 
>> This probably relates to udev configuration in your environment somehow.

I found the problem the device is not detected as bcache by blkid - see
here:

'/sbin/blkid -o udev -p /dev/sdf1'(out) 'ID_FS_AMBIVALENT=other:bcache
other:xfs_external_log'

normally it looks like this:
'/sbin/blkid -o udev -p /dev/sdg1'(out) 'ID_FS_TYPE=bcache'

so instead of setting the FS_TYPE to bcache it's ID_FS_AMBIVALENT which
skips the bcache udev rules.

Just no idea how to fix that.

Stefan

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

[Michael Lyle]

Hey Stefan--

On 11/22/2017 11:42 AM, Stefan Priebe - Profihost AG wrote:
> I found the problem the device is not detected as bcache by blkid - see
> here:
> 
> '/sbin/blkid -o udev -p /dev/sdf1'(out) 'ID_FS_AMBIVALENT=other:bcache
> other:xfs_external_log'
> 
> normally it looks like this:
> '/sbin/blkid -o udev -p /dev/sdg1'(out) 'ID_FS_TYPE=bcache'
> 
> so instead of setting the FS_TYPE to bcache it's ID_FS_AMBIVALENT which
> skips the bcache udev rules.
> 
> Just no idea how to fix that.
> 
> Stefan

Good find.  Can you send me the first 8k of /dev/sdf1?  I'll poke at it
(no promises though).

Mike

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

[Stefan Priebe - Profihost AG]

Am 22.11.2017 um 21:22 schrieb Michael Lyle:
> Hey Stefan--
> 
> On 11/22/2017 11:42 AM, Stefan Priebe - Profihost AG wrote:
>> I found the problem the device is not detected as bcache by blkid - see
>> here:
>>
>> '/sbin/blkid -o udev -p /dev/sdf1'(out) 'ID_FS_AMBIVALENT=other:bcache
>> other:xfs_external_log'
>>
>> normally it looks like this:
>> '/sbin/blkid -o udev -p /dev/sdg1'(out) 'ID_FS_TYPE=bcache'
>>
>> so instead of setting the FS_TYPE to bcache it's ID_FS_AMBIVALENT which
>> skips the bcache udev rules.
>>
>> Just no idea how to fix that.
>>
>> Stefan
> 
> Good find.  Can you send me the first 8k of /dev/sdf1?  I'll poke at it
> (no promises though).

Yes will send in seperate mail.

> 
> Mike
> 

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

[Michael Lyle]

On 11/22/2017 12:36 PM, Stefan Priebe - Profihost AG wrote:
> Am 22.11.2017 um 21:22 schrieb Michael Lyle:
>> Good find.  Can you send me the first 8k of /dev/sdf1?  I'll poke at it
>> (no promises though).
> 
> Yes will send in seperate mail.

mlyle@midnight:~/Downloads$ blkid 8k
8k: UUID="65811163-4ffc-4823-ad72-bae10ce85b63" TYPE="bcache"
mlyle@midnight:~/Downloads$ blkid --version
blkid from util-linux 2.30.1  (libblkid 2.30.1, 20-Jul-2017)

I don't understand, it seems OK.

Mike

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

[Stefan Priebe - Profihost AG]

Am 22.11.2017 um 21:44 schrieb Michael Lyle:
> On 11/22/2017 12:36 PM, Stefan Priebe - Profihost AG wrote:
>> Am 22.11.2017 um 21:22 schrieb Michael Lyle:
>>> Good find.  Can you send me the first 8k of /dev/sdf1?  I'll poke at it
>>> (no promises though).
>>
>> Yes will send in seperate mail.
> 
> mlyle@midnight:~/Downloads$ blkid 8k
> 8k: UUID="65811163-4ffc-4823-ad72-bae10ce85b63" TYPE="bcache"
> mlyle@midnight:~/Downloads$ blkid --version
> blkid from util-linux 2.30.1  (libblkid 2.30.1, 20-Jul-2017)
> 
> I don't understand, it seems OK.
i think i remember that the xfs external log superblock is NOT at the
beginning. Not sure where it is and yes there's an XFS on top of bcache...

Greets,
Stefan

> 
> Mike
> 

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

[Michael Lyle]

On 11/22/2017 12:56 PM, Stefan Priebe - Profihost AG wrote:
> 
> Am 22.11.2017 um 21:44 schrieb Michael Lyle:
>> On 11/22/2017 12:36 PM, Stefan Priebe - Profihost AG wrote:
>>> Am 22.11.2017 um 21:22 schrieb Michael Lyle:
>> mlyle@midnight:~/Downloads$ blkid 8k
>> 8k: UUID="65811163-4ffc-4823-ad72-bae10ce85b63" TYPE="bcache"
>> mlyle@midnight:~/Downloads$ blkid --version
>> blkid from util-linux 2.30.1  (libblkid 2.30.1, 20-Jul-2017)
>>
>> I don't understand, it seems OK.
> i think i remember that the xfs external log superblock is NOT at the
> beginning. Not sure where it is and yes there's an XFS on top of bcache...
> 
> Greets,
> Stefan

It shouldn't be an issue because: A) blkid should "favor" bcache, and B)
the other filesystem data structures should be offset and not at the
position that blkid will be looking for them.  Can you check your blkid
version?

Mike

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

[Stefan Priebe - Profihost AG]

Am 22.11.2017 um 22:03 schrieb Michael Lyle:
> On 11/22/2017 12:56 PM, Stefan Priebe - Profihost AG wrote:
>>
>> Am 22.11.2017 um 21:44 schrieb Michael Lyle:
>>> On 11/22/2017 12:36 PM, Stefan Priebe - Profihost AG wrote:
>>>> Am 22.11.2017 um 21:22 schrieb Michael Lyle:
>>> mlyle@midnight:~/Downloads$ blkid 8k
>>> 8k: UUID="65811163-4ffc-4823-ad72-bae10ce85b63" TYPE="bcache"
>>> mlyle@midnight:~/Downloads$ blkid --version
>>> blkid from util-linux 2.30.1  (libblkid 2.30.1, 20-Jul-2017)
>>>
>>> I don't understand, it seems OK.
>> i think i remember that the xfs external log superblock is NOT at the
>> beginning. Not sure where it is and yes there's an XFS on top of bcache...
>>
>> Greets,
>> Stefan
> 
> It shouldn't be an issue because: A) blkid should "favor" bcache, and B)
> the other filesystem data structures should be offset and not at the
> position that blkid will be looking for them.  Can you check your blkid
> version?

default debian jessie version:
# blkid -v
blkid from util-linux 2.25.2  (libblkid 2.25.0, 24-Oct-2014)

> 
> Mike
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Michael Lyle]

On 11/22/2017 01:07 PM, Stefan Priebe - Profihost AG wrote:
> default debian jessie version:
> # blkid -v
> blkid from util-linux 2.25.2  (libblkid 2.25.0, 24-Oct-2014)

OK, so it's ancient.

One other thing that can get you-- if there was ever an xfs or other
filesystem on this disk -without- bcache, then you created bcache & xfs
on it without wipefs... the old superblock can still be hanging around
and not having happened to been rewritten.

Mike

> 
>>
>> Mike
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Stefan Priebe - Profihost AG]

Am 22.11.2017 um 22:10 schrieb Michael Lyle:
> On 11/22/2017 01:07 PM, Stefan Priebe - Profihost AG wrote:
>> default debian jessie version:
>> # blkid -v
>> blkid from util-linux 2.25.2  (libblkid 2.25.0, 24-Oct-2014)
> 
> OK, so it's ancient.
> 
> One other thing that can get you-- if there was ever an xfs or other
> filesystem on this disk -without- bcache, then you created bcache & xfs
> on it without wipefs... the old superblock can still be hanging around
> and not having happened to been rewritten.

no there shouldn't eb ever an xfs without it on disk - but i can't
guarantee that.

To reproduce the isue you need the first 10MB of the disk.

See below:

Still ok:

# dd if=/dev/sdf1 of=/tmp/8k bs=8M count=1
1+0 records in
1+0 records out
8388608 bytes (8,4 MB) copied, 0,01318 s, 636 MB/s
# /sbin/blkid -o udev -p /tmp/8k
ID_FS_UUID=65811163-4ffc-4823-ad72-bae10ce85b63
ID_FS_UUID_ENC=65811163-4ffc-4823-ad72-bae10ce85b63
ID_FS_TYPE=bcache
ID_FS_USAGE=other

not anymore:

# dd if=/dev/sdf1 of=/tmp/8k bs=10M count=1
1+0 records in
1+0 records out
10485760 bytes (10 MB) copied, 0,0115798 s, 906 MB/s
# /sbin/blkid -o udev -p /tmp/8k
ID_FS_AMBIVALENT=other:bcache other:xfs_external_log

Stefan

> 
> Mike
> 
>>
>>>
>>> Mike
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 

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

[Stefan Priebe - Profihost AG]

Hello,

i got it...

first of all the same issue still applies to util-linux v2.31 which is
the latest upstream version.

# ./blkid --version
lt-blkid from util-linux 2.31  (libblkid 2.31.0, 19-Oct-2017)

# ./blkid -o udev -p /dev/sdf1
ID_FS_AMBIVALENT=other:bcache other:xfs_external_log

The issue is somewhat different. The device is used for ceph which
stores on on that Disk 4MB slices of VM block devices.

So we have:
bcache => XFS on top => thousands of files containing VM images => XFS
in those images

So the xfs_external_log superblock which is seen by blkid is in reality
a superblock of a VM image inside a file which is saved in bcache.

This make even more sense as the system was bootable without any
problems for the last few years without swapping a disk. But somewhat
now a VM image file has exactly positioned it's superblock on a position
blkid expects a superblock.

I see no way to solve it except for changing the udev rules file which
comes with bcache-tools.

Instead of only checking:
ENV{ID_FS_TYPE}=="bcache", GOTO="bcache_backing_found"

it also needs to check for:
ID_FS_AMBIVALENT=other:bcache

Any opinions or suggestions?

Greets,
Stefan

Am 22.11.2017 um 22:13 schrieb Stefan Priebe - Profihost AG:
> 
> Am 22.11.2017 um 22:10 schrieb Michael Lyle:
>> On 11/22/2017 01:07 PM, Stefan Priebe - Profihost AG wrote:
>>> default debian jessie version:
>>> # blkid -v
>>> blkid from util-linux 2.25.2  (libblkid 2.25.0, 24-Oct-2014)
>>
>> OK, so it's ancient.
>>
>> One other thing that can get you-- if there was ever an xfs or other
>> filesystem on this disk -without- bcache, then you created bcache & xfs
>> on it without wipefs... the old superblock can still be hanging around
>> and not having happened to been rewritten.
> 
> no there shouldn't eb ever an xfs without it on disk - but i can't
> guarantee that.
> 
> To reproduce the isue you need the first 10MB of the disk.
> 
> See below:
> 
> Still ok:
> 
> # dd if=/dev/sdf1 of=/tmp/8k bs=8M count=1
> 1+0 records in
> 1+0 records out
> 8388608 bytes (8,4 MB) copied, 0,01318 s, 636 MB/s
> # /sbin/blkid -o udev -p /tmp/8k
> ID_FS_UUID=65811163-4ffc-4823-ad72-bae10ce85b63
> ID_FS_UUID_ENC=65811163-4ffc-4823-ad72-bae10ce85b63
> ID_FS_TYPE=bcache
> ID_FS_USAGE=other
> 
> not anymore:
> 
> # dd if=/dev/sdf1 of=/tmp/8k bs=10M count=1
> 1+0 records in
> 1+0 records out
> 10485760 bytes (10 MB) copied, 0,0115798 s, 906 MB/s
> # /sbin/blkid -o udev -p /tmp/8k
> ID_FS_AMBIVALENT=other:bcache other:xfs_external_log
> 
> Stefan
> 
>>
>> Mike
>>
>>>
>>>>
>>>> Mike
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>

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

[Stefan Priebe - Profihost AG]

ping - nobody? Ideas?

Am 23.11.2017 um 08:10 schrieb Stefan Priebe - Profihost AG:
> Hello,
> 
> i got it...
> 
> first of all the same issue still applies to util-linux v2.31 which is
> the latest upstream version.
> 
> # ./blkid --version
> lt-blkid from util-linux 2.31  (libblkid 2.31.0, 19-Oct-2017)
> 
> # ./blkid -o udev -p /dev/sdf1
> ID_FS_AMBIVALENT=other:bcache other:xfs_external_log
> 
> The issue is somewhat different. The device is used for ceph which
> stores on on that Disk 4MB slices of VM block devices.
> 
> So we have:
> bcache => XFS on top => thousands of files containing VM images => XFS
> in those images
> 
> So the xfs_external_log superblock which is seen by blkid is in reality
> a superblock of a VM image inside a file which is saved in bcache.
> 
> This make even more sense as the system was bootable without any
> problems for the last few years without swapping a disk. But somewhat
> now a VM image file has exactly positioned it's superblock on a position
> blkid expects a superblock.
> 
> I see no way to solve it except for changing the udev rules file which
> comes with bcache-tools.
> 
> Instead of only checking:
> ENV{ID_FS_TYPE}=="bcache", GOTO="bcache_backing_found"
> 
> it also needs to check for:
> ID_FS_AMBIVALENT=other:bcache
> 
> Any opinions or suggestions?
> 
> Greets,
> Stefan
> 
> Am 22.11.2017 um 22:13 schrieb Stefan Priebe - Profihost AG:
>>
>> Am 22.11.2017 um 22:10 schrieb Michael Lyle:
>>> On 11/22/2017 01:07 PM, Stefan Priebe - Profihost AG wrote:
>>>> default debian jessie version:
>>>> # blkid -v
>>>> blkid from util-linux 2.25.2  (libblkid 2.25.0, 24-Oct-2014)
>>>
>>> OK, so it's ancient.
>>>
>>> One other thing that can get you-- if there was ever an xfs or other
>>> filesystem on this disk -without- bcache, then you created bcache & xfs
>>> on it without wipefs... the old superblock can still be hanging around
>>> and not having happened to been rewritten.
>>
>> no there shouldn't eb ever an xfs without it on disk - but i can't
>> guarantee that.
>>
>> To reproduce the isue you need the first 10MB of the disk.
>>
>> See below:
>>
>> Still ok:
>>
>> # dd if=/dev/sdf1 of=/tmp/8k bs=8M count=1
>> 1+0 records in
>> 1+0 records out
>> 8388608 bytes (8,4 MB) copied, 0,01318 s, 636 MB/s
>> # /sbin/blkid -o udev -p /tmp/8k
>> ID_FS_UUID=65811163-4ffc-4823-ad72-bae10ce85b63
>> ID_FS_UUID_ENC=65811163-4ffc-4823-ad72-bae10ce85b63
>> ID_FS_TYPE=bcache
>> ID_FS_USAGE=other
>>
>> not anymore:
>>
>> # dd if=/dev/sdf1 of=/tmp/8k bs=10M count=1
>> 1+0 records in
>> 1+0 records out
>> 10485760 bytes (10 MB) copied, 0,0115798 s, 906 MB/s
>> # /sbin/blkid -o udev -p /tmp/8k
>> ID_FS_AMBIVALENT=other:bcache other:xfs_external_log
>>
>> Stefan
>>
>>>
>>> Mike
>>>
>>>>
>>>>>
>>>>> Mike
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>

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

[Stefan Priebe - Profihost AG]

Am 28.11.2017 um 17:05 schrieb Michael Lyle:
> I don't know.  I don't maintain your userland nor do I know the possible
> implications in your environment.

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 can fix this myself - i just had the hope to get it fixed upstream so
others don't fall into the same issue.

Greets,
Stefan

> Mike
> 
> On Tue, Nov 28, 2017 at 1:36 AM, Stefan Priebe - Profihost AG
> <s.priebe@profihost.ag <mailto:s.priebe@profihost.ag>> wrote:
> 
>     ping - nobody? Ideas?
> 
>     Am 23.11.2017 um 08:10 schrieb Stefan Priebe - Profihost AG:
>     > Hello,
>     >
>     > i got it...
>     >
>     > first of all the same issue still applies to util-linux v2.31 which is
>     > the latest upstream version.
>     >
>     > # ./blkid --version
>     > lt-blkid from util-linux 2.31  (libblkid 2.31.0, 19-Oct-2017)
>     >
>     > # ./blkid -o udev -p /dev/sdf1
>     > ID_FS_AMBIVALENT=other:bcache other:xfs_external_log
>     >
>     > The issue is somewhat different. The device is used for ceph which
>     > stores on on that Disk 4MB slices of VM block devices.
>     >
>     > So we have:
>     > bcache => XFS on top => thousands of files containing VM images => XFS
>     > in those images
>     >
>     > So the xfs_external_log superblock which is seen by blkid is in
>     reality
>     > a superblock of a VM image inside a file which is saved in bcache.
>     >
>     > This make even more sense as the system was bootable without any
>     > problems for the last few years without swapping a disk. But somewhat
>     > now a VM image file has exactly positioned it's superblock on a
>     position
>     > blkid expects a superblock.
>     >
>     > I see no way to solve it except for changing the udev rules file which
>     > comes with bcache-tools.
>     >
>     > Instead of only checking:
>     > ENV{ID_FS_TYPE}=="bcache", GOTO="bcache_backing_found"
>     >
>     > it also needs to check for:
>     > ID_FS_AMBIVALENT=other:bcache
>     >
>     > Any opinions or suggestions?
>     >
>     > Greets,
>     > Stefan
>     >
>     > Am 22.11.2017 um 22:13 schrieb Stefan Priebe - Profihost AG:
>     >>
>     >> Am 22.11.2017 um 22:10 schrieb Michael Lyle:
>     >>> On 11/22/2017 01:07 PM, Stefan Priebe - Profihost AG wrote:
>     >>>> default debian jessie version:
>     >>>> # blkid -v
>     >>>> blkid from util-linux 2.25.2  (libblkid 2.25.0, 24-Oct-2014)
>     >>>
>     >>> OK, so it's ancient.
>     >>>
>     >>> One other thing that can get you-- if there was ever an xfs or other
>     >>> filesystem on this disk -without- bcache, then you created
>     bcache & xfs
>     >>> on it without wipefs... the old superblock can still be hanging
>     around
>     >>> and not having happened to been rewritten.
>     >>
>     >> no there shouldn't eb ever an xfs without it on disk - but i can't
>     >> guarantee that.
>     >>
>     >> To reproduce the isue you need the first 10MB of the disk.
>     >>
>     >> See below:
>     >>
>     >> Still ok:
>     >>
>     >> # dd if=/dev/sdf1 of=/tmp/8k bs=8M count=1
>     >> 1+0 records in
>     >> 1+0 records out
>     >> 8388608 bytes (8,4 MB) copied, 0,01318 s, 636 MB/s
>     >> # /sbin/blkid -o udev -p /tmp/8k
>     >> ID_FS_UUID=65811163-4ffc-4823-ad72-bae10ce85b63
>     >> ID_FS_UUID_ENC=65811163-4ffc-4823-ad72-bae10ce85b63
>     >> ID_FS_TYPE=bcache
>     >> ID_FS_USAGE=other
>     >>
>     >> not anymore:
>     >>
>     >> # dd if=/dev/sdf1 of=/tmp/8k bs=10M count=1
>     >> 1+0 records in
>     >> 1+0 records out
>     >> 10485760 bytes (10 MB) copied, 0,0115798 s, 906 MB/s
>     >> # /sbin/blkid -o udev -p /tmp/8k
>     >> ID_FS_AMBIVALENT=other:bcache other:xfs_external_log
>     >>
>     >> Stefan
>     >>
>     >>>
>     >>> Mike
>     >>>
>     >>>>
>     >>>>>
>     >>>>> Mike
>     >>>>> --
>     >>>>> To unsubscribe from this list: send the line "unsubscribe
>     linux-bcache" in
>     >>>>> the body of a message to majordomo@vger.kernel.org
>     <mailto:majordomo@vger.kernel.org>
>     >>>>> More majordomo info at 
>     http://vger.kernel.org/majordomo-info.html
>     <http://vger.kernel.org/majordomo-info.html>
>     >>>>>
>     >>>> --
>     >>>> To unsubscribe from this list: send the line "unsubscribe
>     linux-bcache" in
>     >>>> the body of a message to majordomo@vger.kernel.org
>     <mailto:majordomo@vger.kernel.org>
>     >>>> More majordomo info at 
>     http://vger.kernel.org/majordomo-info.html
>     <http://vger.kernel.org/majordomo-info.html>
>     >>>>
>     >>>
> 
> 

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

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

This is an issue for your distribution maintainer.

>
> I can fix this myself - i just had the hope to get it fixed upstream so
> others don't fall into the same issue.
>
> Greets,
> Stefan

Mike

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

[Stefan Priebe - Profihost AG]

)

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.

> This is an issue for your distribution maintainer.
> 
>>
>> I can fix this myself - i just had the hope to get it fixed upstream so
>> others don't fall into the same issue.
>>
>> Greets,
>> Stefan
> 
> Mike
> 

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

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

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

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

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

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

[Nix]

On 28 Nov 2017, Stefan Priebe spake thusly:

> Am 28.11.2017 um 21:05 schrieb Michael Lyle:
[...]
>> 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.

bcache can be stacked underneath filesystems via loopback mounts. Heck
you can have a RAID->bcache->LVM->cryptfs->loopback->RAID->bcache stack
if you like (I've done that, though the loopback layers and below were
only for testing.)

-- 
NULL && (void)

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

[Stefan Priebe - Profihost AG]

Am 01.12.2017 um 16:10 schrieb Nix:
> On 28 Nov 2017, Stefan Priebe spake thusly:
> 
>> Am 28.11.2017 um 21:05 schrieb Michael Lyle:
> [...]
>>> 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.
> 
> bcache can be stacked underneath filesystems via loopback mounts. Heck
> you can have a RAID->bcache->LVM->cryptfs->loopback->RAID->bcache stack
> if you like (I've done that, though the loopback layers and below were
> only for testing.)

mhm but that means bcache can't be autoregistered in a solid way. Sad to
here that.

Thanks for your example.

Greets,
Stefan

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

[Michael Lyle]

On 12/10/2017 11:34 AM, Stefan Priebe - Profihost AG wrote:
> 
> Am 01.12.2017 um 16:10 schrieb Nix:
>> bcache can be stacked underneath filesystems via loopback mounts. Heck
>> you can have a RAID->bcache->LVM->cryptfs->loopback->RAID->bcache stack
>> if you like (I've done that, though the loopback layers and below were
>> only for testing.)
> 
> mhm but that means bcache can't be autoregistered in a solid way. Sad to
> here that.

These problems aren't anything specific to bcache.

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

[Stefan Priebe - Profihost AG]

Am 10.12.2017 um 20:36 schrieb Michael Lyle:
> On 12/10/2017 11:34 AM, Stefan Priebe - Profihost AG wrote:
>>
>> Am 01.12.2017 um 16:10 schrieb Nix:
>>> bcache can be stacked underneath filesystems via loopback mounts. Heck
>>> you can have a RAID->bcache->LVM->cryptfs->loopback->RAID->bcache stack
>>> if you like (I've done that, though the loopback layers and below were
>>> only for testing.)
>>
>> mhm but that means bcache can't be autoregistered in a solid way. Sad to
>> here that.
> 
> These problems aren't anything specific to bcache.

sure i didn't meant that - but still bad.

Stefan

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

[Nix]

On 10 Dec 2017, Michael Lyle spake thusly:

> On 12/10/2017 11:34 AM, Stefan Priebe - Profihost AG wrote:
>> 
>> Am 01.12.2017 um 16:10 schrieb Nix:
>>> bcache can be stacked underneath filesystems via loopback mounts. Heck
>>> you can have a RAID->bcache->LVM->cryptfs->loopback->RAID->bcache stack
>>> if you like (I've done that, though the loopback layers and below were
>>> only for testing.)
>> 
>> mhm but that means bcache can't be autoregistered in a solid way. Sad to
>> here that.
>
> These problems aren't anything specific to bcache.

Quite. If you have a crazy stack like that you have to register by hand
at the appropriate time. bcache has uuids, so you should be able to just
try to register everything accessible at each stage, and things will
come together nicely.

-- 
NULL && (void)

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

[Stefan Priebe - Profihost AG]

Am 22.11.2017 um 22:03 schrieb Michael Lyle:
> On 11/22/2017 12:56 PM, Stefan Priebe - Profihost AG wrote:
>>
>> Am 22.11.2017 um 21:44 schrieb Michael Lyle:
>>> On 11/22/2017 12:36 PM, Stefan Priebe - Profihost AG wrote:
>>>> Am 22.11.2017 um 21:22 schrieb Michael Lyle:
>>> mlyle@midnight:~/Downloads$ blkid 8k
>>> 8k: UUID="65811163-4ffc-4823-ad72-bae10ce85b63" TYPE="bcache"
>>> mlyle@midnight:~/Downloads$ blkid --version
>>> blkid from util-linux 2.30.1  (libblkid 2.30.1, 20-Jul-2017)
>>>
>>> I don't understand, it seems OK.
>> i think i remember that the xfs external log superblock is NOT at the
>> beginning. Not sure where it is and yes there's an XFS on top of bcache...
>>
>> Greets,
>> Stefan
> 
> It shouldn't be an issue because: A) blkid should "favor" bcache, and B)
> the other filesystem data structures should be offset and not at the
> position that blkid will be looking for them.  Can you check your blkid
> version?

If you strace blkid you see that it seeks several positions and reads them.

Exmaple:
read(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
4096) = 4096
lseek(3, 0, SEEK_SET)                   = 0
read(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
1024) = 1024
lseek(3, 1024, SEEK_SET)                = 1024
read(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
1024) = 1024
lseek(3, 1048576, SEEK_SET)             = 1048576
read(3,
"ABTB\0\0\1\36\0\0\1\310\0\0\0\215\0029\335\334\0\0\0070\0029\355\f\0\0\4\0"...,
1024) = 1024
lseek(3, 3072, SEEK_SET)                = 3072
read(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
1024) = 1024
lseek(3, 7168, SEEK_SET)                = 7168
read(3,
"\0\0\232\352\0\0\0\26\0\0\233\301\0\0\0\20\0\0\234\21\0\0\0\34\0\0\234.\0\0\0\1"...,
1024) = 1024
lseek(3, 15360, SEEK_SET)               = 15360
read(3,
"\0\0'\353\0\0\0\1\0\0'\353\0\0\0\1\0\0'\353\0\0\0\1\0\0'\353\0\0\0\1"...,
1024) = 1024
lseek(3, 31744, SEEK_SET)               = 31744
read(3,
"\0\10\340\346\0\0\0\30\0\10\340\346\0\0\0\30drmtwsS0l\n1gKn80"...,
1024) = 1024
lseek(3, 64512, SEEK_SET)               = 64512
read(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
1024) = 1024
lseek(3, 0, SEEK_SET)                   = 0
mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7efe60612000
read(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
262144) = 262144
lseek(3, 393216, SEEK_SET)              = 393216

> 
> Mike
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Michael Lyle]

On Wed, Nov 22, 2017 at 1:10 PM, Stefan Priebe - Profihost AG
<s.priebe@profihost.ag> wrote:
> If you strace blkid you see that it seeks several positions and reads them.

Yes, of course, but that doesn't change that an XFS superblock within
a bcache will not be at the expected offset on the backing device.

Mike

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

[Kai Krakow]

Am Wed, 22 Nov 2017 20:42:20 +0100
schrieb Stefan Priebe - Profihost AG <s.priebe@profihost.ag>:

> Hi Coly,
>   Hi Michael,
> 
> 
> Am 22.11.2017 um 20:06 schrieb Stefan Priebe - Profihost AG:
> > Am 22.11.2017 um 18:51 schrieb Michael Lyle:  
> >> Hi Coly, Stefan--
> >>
> >> On 11/22/2017 05:14 AM, Stefan Priebe - Profihost AG wrote:  
>  [...]  
>  [...]  
> >>
> >> I don't think there's any chance this patch will do anything.  If
> >> there's a deadlock, the whole thing will become stuck forever and
> >> never allow registration or progress on the device again-- which
> >> doesn't match the symptoms here.  
> > 
> > No it does not ;-)
> >   
> >> This probably relates to udev configuration in your environment
> >> somehow.  
> 
> I found the problem the device is not detected as bcache by blkid -
> see here:
> 
> '/sbin/blkid -o udev -p /dev/sdf1'(out) 'ID_FS_AMBIVALENT=other:bcache
> other:xfs_external_log'
> 
> normally it looks like this:
> '/sbin/blkid -o udev -p /dev/sdg1'(out) 'ID_FS_TYPE=bcache'
> 
> so instead of setting the FS_TYPE to bcache it's ID_FS_AMBIVALENT
> which skips the bcache udev rules.
> 
> Just no idea how to fix that.

Maybe move bcache ontop of other FS in /etc/filesystems?

There's maybe an orphan XFS superblock hanging around. You could
disassemble the bcache device, wipefs, and recreate.


-- 
Regards,
Kai

Replies to list-only preferred.

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

[Stefan Priebe - Profihost AG]

Am 23.11.2017 um 12:43 schrieb Kai Krakow:
> Am Wed, 22 Nov 2017 20:42:20 +0100
> schrieb Stefan Priebe - Profihost AG <s.priebe@profihost.ag>:
> 
>> Hi Coly,
>>   Hi Michael,
>>
>>
>> Am 22.11.2017 um 20:06 schrieb Stefan Priebe - Profihost AG:
>>> Am 22.11.2017 um 18:51 schrieb Michael Lyle:  
>>>> Hi Coly, Stefan--
>>>>
>>>> On 11/22/2017 05:14 AM, Stefan Priebe - Profihost AG wrote:  
>>  [...]  
>>  [...]  
>>>>
>>>> I don't think there's any chance this patch will do anything.  If
>>>> there's a deadlock, the whole thing will become stuck forever and
>>>> never allow registration or progress on the device again-- which
>>>> doesn't match the symptoms here.  
>>>
>>> No it does not ;-)
>>>   
>>>> This probably relates to udev configuration in your environment
>>>> somehow.  
>>
>> I found the problem the device is not detected as bcache by blkid -
>> see here:
>>
>> '/sbin/blkid -o udev -p /dev/sdf1'(out) 'ID_FS_AMBIVALENT=other:bcache
>> other:xfs_external_log'
>>
>> normally it looks like this:
>> '/sbin/blkid -o udev -p /dev/sdg1'(out) 'ID_FS_TYPE=bcache'
>>
>> so instead of setting the FS_TYPE to bcache it's ID_FS_AMBIVALENT
>> which skips the bcache udev rules.
>>
>> Just no idea how to fix that.
> 
> Maybe move bcache ontop of other FS in /etc/filesystems?
> 
> There's maybe an orphan XFS superblock hanging around. You could
> disassemble the bcache device, wipefs, and recreate.

That won't help - see my email from today.

Thanks!

Stefan