* ont out of 6 bcache devices does not register automatically @ 2017-11-22 11:23 Stefan Priebe - Profihost AG 2017-11-22 12:16 ` Coly Li 0 siblings, 1 reply; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-11-22 11:23 UTC (permalink / raw) To: linux-bcache 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" ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 11:23 ont out of 6 bcache devices does not register automatically Stefan Priebe - Profihost AG @ 2017-11-22 12:16 ` Coly Li 2017-11-22 12:26 ` Stefan Priebe - Profihost AG 0 siblings, 1 reply; 36+ messages in thread From: Coly Li @ 2017-11-22 12:16 UTC (permalink / raw) To: Stefan Priebe - Profihost AG, linux-bcache 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 12:16 ` Coly Li @ 2017-11-22 12:26 ` Stefan Priebe - Profihost AG 2017-11-22 12:57 ` Coly Li 0 siblings, 1 reply; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-11-22 12:26 UTC (permalink / raw) To: Coly Li, linux-bcache 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 >> > > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 12:26 ` Stefan Priebe - Profihost AG @ 2017-11-22 12:57 ` Coly Li 2017-11-22 13:14 ` Stefan Priebe - Profihost AG 0 siblings, 1 reply; 36+ messages in thread From: Coly Li @ 2017-11-22 12:57 UTC (permalink / raw) To: Stefan Priebe - Profihost AG; +Cc: linux-bcache 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 12:57 ` Coly Li @ 2017-11-22 13:14 ` Stefan Priebe - Profihost AG 2017-11-22 13:29 ` Coly Li 2017-11-22 17:51 ` Michael Lyle 0 siblings, 2 replies; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-11-22 13:14 UTC (permalink / raw) To: Coly Li; +Cc: linux-bcache 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 >>>> >>> >>> > > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 13:14 ` Stefan Priebe - Profihost AG @ 2017-11-22 13:29 ` Coly Li 2017-11-22 14:16 ` Stefan Priebe - Profihost AG 2017-11-22 17:51 ` Michael Lyle 1 sibling, 1 reply; 36+ messages in thread From: Coly Li @ 2017-11-22 13:29 UTC (permalink / raw) To: Stefan Priebe - Profihost AG; +Cc: linux-bcache 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 13:29 ` Coly Li @ 2017-11-22 14:16 ` Stefan Priebe - Profihost AG 2017-11-22 15:51 ` Coly Li 0 siblings, 1 reply; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-11-22 14:16 UTC (permalink / raw) To: Coly Li; +Cc: linux-bcache 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 > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 14:16 ` Stefan Priebe - Profihost AG @ 2017-11-22 15:51 ` Coly Li 2017-11-22 19:07 ` Stefan Priebe - Profihost AG 0 siblings, 1 reply; 36+ messages in thread From: Coly Li @ 2017-11-22 15:51 UTC (permalink / raw) To: Stefan Priebe - Profihost AG; +Cc: linux-bcache 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 15:51 ` Coly Li @ 2017-11-22 19:07 ` Stefan Priebe - Profihost AG 0 siblings, 0 replies; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-11-22 19:07 UTC (permalink / raw) To: Coly Li; +Cc: linux-bcache 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 > > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 13:14 ` Stefan Priebe - Profihost AG 2017-11-22 13:29 ` Coly Li @ 2017-11-22 17:51 ` Michael Lyle 2017-11-22 19:06 ` Stefan Priebe - Profihost AG 1 sibling, 1 reply; 36+ messages in thread From: Michael Lyle @ 2017-11-22 17:51 UTC (permalink / raw) To: Stefan Priebe - Profihost AG, Coly Li; +Cc: linux-bcache 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 17:51 ` Michael Lyle @ 2017-11-22 19:06 ` Stefan Priebe - Profihost AG 2017-11-22 19:42 ` Stefan Priebe - Profihost AG 0 siblings, 1 reply; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-11-22 19:06 UTC (permalink / raw) To: Michael Lyle, Coly Li; +Cc: linux-bcache 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 > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 19:06 ` Stefan Priebe - Profihost AG @ 2017-11-22 19:42 ` Stefan Priebe - Profihost AG 2017-11-22 20:22 ` Michael Lyle 2017-11-23 11:43 ` Kai Krakow 0 siblings, 2 replies; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-11-22 19:42 UTC (permalink / raw) To: Michael Lyle, Coly Li; +Cc: linux-bcache 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 19:42 ` Stefan Priebe - Profihost AG @ 2017-11-22 20:22 ` Michael Lyle 2017-11-22 20:36 ` Stefan Priebe - Profihost AG 2017-11-23 11:43 ` Kai Krakow 1 sibling, 1 reply; 36+ messages in thread From: Michael Lyle @ 2017-11-22 20:22 UTC (permalink / raw) To: Stefan Priebe - Profihost AG, Coly Li; +Cc: linux-bcache 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 20:22 ` Michael Lyle @ 2017-11-22 20:36 ` Stefan Priebe - Profihost AG 2017-11-22 20:44 ` Michael Lyle 0 siblings, 1 reply; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-11-22 20:36 UTC (permalink / raw) To: Michael Lyle, Coly Li; +Cc: linux-bcache 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 > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 20:36 ` Stefan Priebe - Profihost AG @ 2017-11-22 20:44 ` Michael Lyle 2017-11-22 20:56 ` Stefan Priebe - Profihost AG 0 siblings, 1 reply; 36+ messages in thread From: Michael Lyle @ 2017-11-22 20:44 UTC (permalink / raw) To: Stefan Priebe - Profihost AG, Coly Li; +Cc: linux-bcache 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 20:44 ` Michael Lyle @ 2017-11-22 20:56 ` Stefan Priebe - Profihost AG 2017-11-22 21:03 ` Michael Lyle 0 siblings, 1 reply; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-11-22 20:56 UTC (permalink / raw) To: Michael Lyle, Coly Li; +Cc: linux-bcache 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 > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 20:56 ` Stefan Priebe - Profihost AG @ 2017-11-22 21:03 ` Michael Lyle 2017-11-22 21:07 ` Stefan Priebe - Profihost AG 2017-11-22 21:10 ` Stefan Priebe - Profihost AG 0 siblings, 2 replies; 36+ messages in thread From: Michael Lyle @ 2017-11-22 21:03 UTC (permalink / raw) To: Stefan Priebe - Profihost AG, Coly Li; +Cc: linux-bcache 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 21:03 ` Michael Lyle @ 2017-11-22 21:07 ` Stefan Priebe - Profihost AG 2017-11-22 21:10 ` Michael Lyle 2017-11-22 21:10 ` Stefan Priebe - Profihost AG 1 sibling, 1 reply; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-11-22 21:07 UTC (permalink / raw) To: Michael Lyle, Coly Li; +Cc: linux-bcache 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 > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 21:07 ` Stefan Priebe - Profihost AG @ 2017-11-22 21:10 ` Michael Lyle 2017-11-22 21:13 ` Stefan Priebe - Profihost AG 0 siblings, 1 reply; 36+ messages in thread From: Michael Lyle @ 2017-11-22 21:10 UTC (permalink / raw) To: Stefan Priebe - Profihost AG, Coly Li; +Cc: linux-bcache 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 > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 21:10 ` Michael Lyle @ 2017-11-22 21:13 ` Stefan Priebe - Profihost AG 2017-11-23 7:10 ` Stefan Priebe - Profihost AG 0 siblings, 1 reply; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-11-22 21:13 UTC (permalink / raw) To: Michael Lyle, Coly Li; +Cc: linux-bcache 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 >> > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 21:13 ` Stefan Priebe - Profihost AG @ 2017-11-23 7:10 ` Stefan Priebe - Profihost AG 2017-11-28 9:36 ` Stefan Priebe - Profihost AG 0 siblings, 1 reply; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-11-23 7:10 UTC (permalink / raw) To: Michael Lyle, Coly Li; +Cc: linux-bcache, n.fahldieck 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 >>> >> ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-23 7:10 ` Stefan Priebe - Profihost AG @ 2017-11-28 9:36 ` Stefan Priebe - Profihost AG [not found] ` <CAJ+L6qc79S1t10WfeycRFLesuqbZNfUXrN7qo6fVuwbHk=n8xw@mail.gmail.com> 0 siblings, 1 reply; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-11-28 9:36 UTC (permalink / raw) To: Michael Lyle, Coly Li; +Cc: linux-bcache, n.fahldieck 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 >>>> >>> ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <CAJ+L6qc79S1t10WfeycRFLesuqbZNfUXrN7qo6fVuwbHk=n8xw@mail.gmail.com>]
* Re: ont out of 6 bcache devices does not register automatically [not found] ` <CAJ+L6qc79S1t10WfeycRFLesuqbZNfUXrN7qo6fVuwbHk=n8xw@mail.gmail.com> @ 2017-11-28 19:32 ` Stefan Priebe - Profihost AG 2017-11-28 19:51 ` Michael Lyle 0 siblings, 1 reply; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-11-28 19:32 UTC (permalink / raw) To: Michael Lyle; +Cc: Coly Li, linux-bcache, n.fahldieck 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> > >>>> > >>> > > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-28 19:32 ` Stefan Priebe - Profihost AG @ 2017-11-28 19:51 ` Michael Lyle 2017-11-28 19:59 ` Stefan Priebe - Profihost AG 0 siblings, 1 reply; 36+ messages in thread From: Michael Lyle @ 2017-11-28 19:51 UTC (permalink / raw) To: Stefan Priebe - Profihost AG; +Cc: Coly Li, linux-bcache, n.fahldieck 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-28 19:51 ` Michael Lyle @ 2017-11-28 19:59 ` Stefan Priebe - Profihost AG 2017-11-28 20:05 ` Michael Lyle 0 siblings, 1 reply; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-11-28 19:59 UTC (permalink / raw) To: Michael Lyle; +Cc: Coly Li, linux-bcache, n.fahldieck ) 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 > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-28 19:59 ` Stefan Priebe - Profihost AG @ 2017-11-28 20:05 ` Michael Lyle 2017-11-28 20:31 ` Stefan Priebe - Profihost AG 0 siblings, 1 reply; 36+ messages in thread From: Michael Lyle @ 2017-11-28 20:05 UTC (permalink / raw) To: Stefan Priebe - Profihost AG; +Cc: Coly Li, linux-bcache, n.fahldieck 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-28 20:05 ` Michael Lyle @ 2017-11-28 20:31 ` Stefan Priebe - Profihost AG 2017-12-01 15:10 ` Nix 0 siblings, 1 reply; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-11-28 20:31 UTC (permalink / raw) To: Michael Lyle; +Cc: Coly Li, linux-bcache, n.fahldieck 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 > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-28 20:31 ` Stefan Priebe - Profihost AG @ 2017-12-01 15:10 ` Nix 2017-12-10 19:34 ` Stefan Priebe - Profihost AG 0 siblings, 1 reply; 36+ messages in thread From: Nix @ 2017-12-01 15:10 UTC (permalink / raw) To: Stefan Priebe - Profihost AG Cc: Michael Lyle, Coly Li, linux-bcache, n.fahldieck 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) ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-12-01 15:10 ` Nix @ 2017-12-10 19:34 ` Stefan Priebe - Profihost AG 2017-12-10 19:36 ` Michael Lyle 0 siblings, 1 reply; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-12-10 19:34 UTC (permalink / raw) To: Nix; +Cc: Michael Lyle, Coly Li, linux-bcache, n.fahldieck 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-12-10 19:34 ` Stefan Priebe - Profihost AG @ 2017-12-10 19:36 ` Michael Lyle 2017-12-10 19:39 ` Stefan Priebe - Profihost AG 2017-12-12 15:38 ` Nix 0 siblings, 2 replies; 36+ messages in thread From: Michael Lyle @ 2017-12-10 19:36 UTC (permalink / raw) To: Stefan Priebe - Profihost AG, Nix; +Cc: Coly Li, linux-bcache, n.fahldieck 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-12-10 19:36 ` Michael Lyle @ 2017-12-10 19:39 ` Stefan Priebe - Profihost AG 2017-12-12 15:38 ` Nix 1 sibling, 0 replies; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-12-10 19:39 UTC (permalink / raw) To: Michael Lyle, Nix; +Cc: Coly Li, linux-bcache, n.fahldieck 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-12-10 19:36 ` Michael Lyle 2017-12-10 19:39 ` Stefan Priebe - Profihost AG @ 2017-12-12 15:38 ` Nix 1 sibling, 0 replies; 36+ messages in thread From: Nix @ 2017-12-12 15:38 UTC (permalink / raw) To: Michael Lyle Cc: Stefan Priebe - Profihost AG, Coly Li, linux-bcache, n.fahldieck 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) ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 21:03 ` Michael Lyle 2017-11-22 21:07 ` Stefan Priebe - Profihost AG @ 2017-11-22 21:10 ` Stefan Priebe - Profihost AG 2017-11-22 21:13 ` Michael Lyle 1 sibling, 1 reply; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-11-22 21:10 UTC (permalink / raw) To: Michael Lyle, Coly Li; +Cc: linux-bcache 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 > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 21:10 ` Stefan Priebe - Profihost AG @ 2017-11-22 21:13 ` Michael Lyle 0 siblings, 0 replies; 36+ messages in thread From: Michael Lyle @ 2017-11-22 21:13 UTC (permalink / raw) To: Stefan Priebe - Profihost AG; +Cc: Coly Li, linux-bcache 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-22 19:42 ` Stefan Priebe - Profihost AG 2017-11-22 20:22 ` Michael Lyle @ 2017-11-23 11:43 ` Kai Krakow 2017-11-23 12:03 ` Stefan Priebe - Profihost AG 1 sibling, 1 reply; 36+ messages in thread From: Kai Krakow @ 2017-11-23 11:43 UTC (permalink / raw) To: linux-bcache 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ont out of 6 bcache devices does not register automatically 2017-11-23 11:43 ` Kai Krakow @ 2017-11-23 12:03 ` Stefan Priebe - Profihost AG 0 siblings, 0 replies; 36+ messages in thread From: Stefan Priebe - Profihost AG @ 2017-11-23 12:03 UTC (permalink / raw) To: Kai Krakow, linux-bcache 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2017-12-12 15:39 UTC | newest] Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-11-22 11:23 ont out of 6 bcache devices does not register automatically Stefan Priebe - Profihost AG 2017-11-22 12:16 ` Coly Li 2017-11-22 12:26 ` Stefan Priebe - Profihost AG 2017-11-22 12:57 ` Coly Li 2017-11-22 13:14 ` Stefan Priebe - Profihost AG 2017-11-22 13:29 ` Coly Li 2017-11-22 14:16 ` Stefan Priebe - Profihost AG 2017-11-22 15:51 ` Coly Li 2017-11-22 19:07 ` Stefan Priebe - Profihost AG 2017-11-22 17:51 ` Michael Lyle 2017-11-22 19:06 ` Stefan Priebe - Profihost AG 2017-11-22 19:42 ` Stefan Priebe - Profihost AG 2017-11-22 20:22 ` Michael Lyle 2017-11-22 20:36 ` Stefan Priebe - Profihost AG 2017-11-22 20:44 ` Michael Lyle 2017-11-22 20:56 ` Stefan Priebe - Profihost AG 2017-11-22 21:03 ` Michael Lyle 2017-11-22 21:07 ` Stefan Priebe - Profihost AG 2017-11-22 21:10 ` Michael Lyle 2017-11-22 21:13 ` Stefan Priebe - Profihost AG 2017-11-23 7:10 ` Stefan Priebe - Profihost AG 2017-11-28 9:36 ` Stefan Priebe - Profihost AG [not found] ` <CAJ+L6qc79S1t10WfeycRFLesuqbZNfUXrN7qo6fVuwbHk=n8xw@mail.gmail.com> 2017-11-28 19:32 ` Stefan Priebe - Profihost AG 2017-11-28 19:51 ` Michael Lyle 2017-11-28 19:59 ` Stefan Priebe - Profihost AG 2017-11-28 20:05 ` Michael Lyle 2017-11-28 20:31 ` Stefan Priebe - Profihost AG 2017-12-01 15:10 ` Nix 2017-12-10 19:34 ` Stefan Priebe - Profihost AG 2017-12-10 19:36 ` Michael Lyle 2017-12-10 19:39 ` Stefan Priebe - Profihost AG 2017-12-12 15:38 ` Nix 2017-11-22 21:10 ` Stefan Priebe - Profihost AG 2017-11-22 21:13 ` Michael Lyle 2017-11-23 11:43 ` Kai Krakow 2017-11-23 12:03 ` Stefan Priebe - Profihost AG
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.