Bcache explodes when trying to attach

Bcache explodes when trying to attach

[Brad Campbell]

I'm trying bcache merged with linus' git head (-rc9). I suppose I should really try it with a 
vanilla bcache-dev tree.

Anyway, I can register the cache and backing device but when I try and attach the cache set to the 
backing device this happens :

Cache is /dev/sde. Backing device is /dev/md10 (4 disk RAID10)

[  129.896180] bio: create slab <bio-2> at 2
[  129.972092] bcache: journal replay done, 0 keys in 2 entries, seq 1-2
[  157.704117] md: resync of RAID array md10
[  157.704161] ------------[ cut here ]------------
[  157.704168] kernel BUG at drivers/scsi/scsi_lib.c:1152!
[  157.704174] invalid opcode: 0000 [#1] SMP
[  157.704179] CPU 0
[  157.704181] Modules linked in: nfs ipt_MASQUERADE xt_tcpudp iptable_filter iptable_nat nf_nat 
nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables deflate zlib_deflate des_generic 
cbc ecb crypto_blkcipher sha1_generic md5 hmac crypto_hash cryptomgr aead crypto_algapi af_key fuse 
w83627ehf hwmon_vid netconsole configfs vhost_net powernow_k8 mperf kvm_amd kvm i2c_piix4 xhci_hcd 
k10temp ohci_hcd ehci_hcd atl1c ahci libahci usbcore megaraid_sas [last unloaded: scsi_wait_scan]
[  157.704233]
[  157.704239] Pid: 1422, comm: md10_raid10 Not tainted 3.1.0-rc9-00143-g9468c19 #5 To Be Filled By 
O.E.M. To Be Filled By O.E.M./890GX Extreme4 R2.0
[  157.704249] RIP: 0010:[<ffffffff812a541e>]  [<ffffffff812a541e>] scsi_setup_fs_cmnd+0xae/0xf0
[  157.704263] RSP: 0018:ffff88041ba33be0  EFLAGS: 00010046
[  157.704268] RAX: 0000000000000000 RBX: ffff88041bbe3428 RCX: 0000000000001000
[  157.704273] RDX: 0000000000000000 RSI: ffff88041bbe3428 RDI: ffff88041d42b000
[  157.704278] RBP: ffff88041d42b000 R08: 0000000000000000 R09: 0000000000000001
[  157.704282] R10: a080000000000000 R11: dead000000100100 R12: ffff88041d42b000
[  157.704287] R13: 000000000e9c3408 R14: ffff88041d42b048 R15: ffff88041c6a7400
[  157.704293] FS:  00007fa45e67e700(0000) GS:ffff88042fc00000(0000) knlGS:0000000000000000
[  157.704298] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  157.704305] CR2: 0000000000824008 CR3: 0000000407f12000 CR4: 00000000000006f0
[  157.704309] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  157.704314] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  157.704320] Process md10_raid10 (pid: 1422, threadinfo ffff88041ba32000, task ffff88041c779880)
[  157.704323] Stack:
[  157.704326]  0000000000000000 ffff88041bbe3428 ffff88041b998000 ffffffff812aff1c
[  157.704333]  01ff88041d42b800 ffff880400000001 ffff880400001000 0000000000000000
[  157.704339]  ffff88041bbe3428 ffff88041bbe3428 ffff88041bbe3428 ffff88041b998000
[  157.704346] Call Trace:
[  157.704356]  [<ffffffff812aff1c>] ? sd_prep_fn+0x15c/0xa50
[  157.704364]  [<ffffffff811c29e4>] ? blk_peek_request+0xb4/0x1d0
[  157.704371]  [<ffffffff812a4940>] ? scsi_request_fn+0x50/0x4a0
[  157.704377]  [<ffffffff811c3398>] ? blk_flush_plug_list+0x188/0x210
[  157.704384]  [<ffffffff811c342b>] ? blk_finish_plug+0xb/0x30
[  157.704392]  [<ffffffff812f2688>] ? raid10d+0x908/0xb50
[  157.704400]  [<ffffffff813ffed5>] ? schedule_timeout+0x1c5/0x230
[  157.704408]  [<ffffffff81055e91>] ? sched_clock_cpu+0x61/0xf0
[  157.704415]  [<ffffffff8130649f>] ? md_thread+0x10f/0x140
[  157.704423]  [<ffffffff81050130>] ? wake_up_bit+0x40/0x40
[  157.704430]  [<ffffffff81306390>] ? md_register_thread+0x100/0x100
[  157.704437]  [<ffffffff81306390>] ? md_register_thread+0x100/0x100
[  157.704443]  [<ffffffff8104fcd6>] ? kthread+0x96/0xa0
[  157.704452]  [<ffffffff814030f4>] ? kernel_thread_helper+0x4/0x10
[  157.704459]  [<ffffffff8104fc40>] ? kthread_worker_fn+0x120/0x120
[  157.704467]  [<ffffffff814030f0>] ? gs_change+0xb/0xb
[  157.704470] Code: 80 00 00 00 00 48 83 c4 08 5b 5d c3 90 48 89 ef be 20 00 00 00 e8 73 a2 ff ff 
48 85 c0 48 89 c7 74 d7 48 89 83 d8 00 00 00 eb 8d <0f> 0b eb fe 48 8b 00 48 85 c0 0f 84 67 ff ff ff 
48 8b 40 50 48
[  157.704510] RIP  [<ffffffff812a541e>] scsi_setup_fs_cmnd+0xae/0xf0
[  157.704517]  RSP <ffff88041ba33be0>
[  157.704522] ---[ end trace 3cdc1163f94b6a24 ]---
[  157.704526] Kernel panic - not syncing: Fatal exception
[  157.704532] Pid: 1422, comm: md10_raid10 Tainted: G      D     3.1.0-rc9-00143-g9468c19 #5
[  157.704536] Call Trace:
[  157.704542]  [<ffffffff813feb89>] ? panic+0x92/0x193
[  157.704549]  [<ffffffff81035341>] ? kmsg_dump+0x41/0xf0
[  157.704557]  [<ffffffff8100504d>] ? oops_end+0x8d/0xa0
[  157.704564]  [<ffffffff81002e34>] ? do_invalid_op+0x84/0xa0
[  157.704569]  [<ffffffff812a541e>] ? scsi_setup_fs_cmnd+0xae/0xf0
[  157.704577]  [<ffffffff811d078e>] ? cfq_set_request+0x15e/0x3b0
[  157.704584]  [<ffffffff81402f75>] ? invalid_op+0x15/0x20
[  157.704590]  [<ffffffff812a541e>] ? scsi_setup_fs_cmnd+0xae/0xf0
[  157.704598]  [<ffffffff812aff1c>] ? sd_prep_fn+0x15c/0xa50
[  157.704604]  [<ffffffff811c29e4>] ? blk_peek_request+0xb4/0x1d0
[  157.704609]  [<ffffffff812a4940>] ? scsi_request_fn+0x50/0x4a0
[  157.704615]  [<ffffffff811c3398>] ? blk_flush_plug_list+0x188/0x210
[  157.704622]  [<ffffffff811c342b>] ? blk_finish_plug+0xb/0x30
[  157.704628]  [<ffffffff812f2688>] ? raid10d+0x908/0xb50
[  157.704635]  [<ffffffff813ffed5>] ? schedule_timeout+0x1c5/0x230
[  157.704641]  [<ffffffff81055e91>] ? sched_clock_cpu+0x61/0xf0
[  157.704648]  [<ffffffff8130649f>] ? md_thread+0x10f/0x140
[  157.704655]  [<ffffffff81050130>] ? wake_up_bit+0x40/0x40
[  157.704661]  [<ffffffff81306390>] ? md_register_thread+0x100/0x100
[  157.704668]  [<ffffffff81306390>] ? md_register_thread+0x100/0x100
[  157.704675]  [<ffffffff8104fcd6>] ? kthread+0x96/0xa0
[  157.704682]  [<ffffffff814030f4>] ? kernel_thread_helper+0x4/0x10
[  157.704689]  [<ffffffff8104fc40>] ? kthread_worker_fn+0x120/0x120
[  157.704696]  [<ffffffff814030f0>] ? gs_change+0xb/0xb
[  157.707104] Rebooting in 10 seconds..

Re: Bcache explodes when trying to attach

[Brad Campbell]

On 15/10/11 13:43, Brad Campbell wrote:
> I'm trying bcache merged with linus' git head (-rc9). I suppose I should really try it with a 
> vanilla bcache-dev tree.
>
> Anyway, I can register the cache and backing device but when I try and attach the cache set to the 
> backing device this happens :

Ok, so the build was broken in some odd way. Turns out the latest git does not build unless you have 
cgroups enabled (which by default I don't).

This came from the same scenario using a vanilla bcache git clone..

[  162.412296] bio: create slab <bio-2> at 2
[  162.441711] bcache: journal entries 3-4 missing! (replaying 2-4)
[  162.441805] bcache: journal replay done, 0 keys in 2 entries, seq 2-4
[  181.955480] md: resync of RAID array md10
[  181.955526] ------------[ cut here ]------------
[  181.955533] kernel BUG at drivers/scsi/scsi_lib.c:1152!
[  181.955539] invalid opcode: 0000 [#1] SMP
[  181.955546] CPU 1
[  181.955549] Modules linked in: nfs ipt_MASQUERADE xt_tcpudp iptable_filter iptable_nat nf_nat 
nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables deflate zlib_deflate des_generic 
cbc ecb crypto_blkcipher sha1_generic md5 hmac crypto_hash cryptomgr aead crypto_algapi af_key fuse 
w83627ehf hwmon_vid netconsole configfs vhost_net powernow_k8 mperf kvm_amd kvm xhci_hcd i2c_piix4 
k10temp ohci_hcd ehci_hcd usbcore ahci libahci atl1c megaraid_sas [last unloaded: scsi_wait_scan]
[  181.955600]
[  181.955606] Pid: 1422, comm: md10_raid10 Not tainted 3.1.0-rc9-00152-g3900b5a-dirty #6 To Be 
Filled By O.E.M. To Be Filled By O.E.M./890GX Extreme4 R2.0
[  181.955616] RIP: 0010:[<ffffffff812ad4ee>]  [<ffffffff812ad4ee>] scsi_setup_fs_cmnd+0xae/0xf0
[  181.955631] RSP: 0018:ffff88041bfdbbe0  EFLAGS: 00010046
[  181.955636] RAX: 0000000000000000 RBX: ffff88041c4d3830 RCX: 0000000000001000
[  181.955641] RDX: 0000000000000000 RSI: ffff88041c4d3830 RDI: ffff88041c754800
[  181.955645] RBP: ffff88041c754800 R08: 0000000000000000 R09: 0000000000000001
[  181.955650] R10: 4080000000000000 R11: 0000000000000000 R12: ffff88041c754800
[  181.955654] R13: 0000000000000808 R14: ffff88041c754848 R15: ffff88041c3cbc00
[  181.955661] FS:  00007fc823617700(0000) GS:ffff88042fc40000(0000) knlGS:0000000000000000
[  181.955668] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  181.955672] CR2: ffffffffff600400 CR3: 00000003ffe02000 CR4: 00000000000006e0
[  181.955677] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  181.955681] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  181.955687] Process md10_raid10 (pid: 1422, threadinfo ffff88041bfda000, task ffff88041c1bcb00)
[  181.955691] Stack:
[  181.955693]  0000000000000000 ffff88041c4d3830 ffff88041bd83c30 ffffffff812b7fec
[  181.955701]  01ff88041c755000 ffff880400000001 ffff880400001000 0000000000000000
[  181.955707]  ffff88041c4d3830 ffff88041c4d3830 ffff88041c4d3830 ffff88041bd83c30
[  181.955714] Call Trace:
[  181.955723]  [<ffffffff812b7fec>] ? sd_prep_fn+0x15c/0xa50
[  181.955732]  [<ffffffff811c8c04>] ? blk_peek_request+0xb4/0x1d0
[  181.955739]  [<ffffffff812aca10>] ? scsi_request_fn+0x50/0x4a0
[  181.955747]  [<ffffffff811c95b8>] ? blk_flush_plug_list+0x188/0x210
[  181.955755]  [<ffffffff811c964b>] ? blk_finish_plug+0xb/0x30
[  181.955762]  [<ffffffff812fa768>] ? raid10d+0x908/0xb50
[  181.955770]  [<ffffffff81041183>] ? lock_timer_base+0x33/0x70
[  181.955779]  [<ffffffff814082b5>] ? schedule_timeout+0x1c5/0x230
[  181.955786]  [<ffffffff8130e57f>] ? md_thread+0x10f/0x140
[  181.955795]  [<ffffffff81050260>] ? wake_up_bit+0x40/0x40
[  181.955801]  [<ffffffff8130e470>] ? md_register_thread+0x100/0x100
[  181.955807]  [<ffffffff8130e470>] ? md_register_thread+0x100/0x100
[  181.955814]  [<ffffffff8104fe06>] ? kthread+0x96/0xa0
[  181.955821]  [<ffffffff8140b4f4>] ? kernel_thread_helper+0x4/0x10
[  181.955829]  [<ffffffff8104fd70>] ? kthread_worker_fn+0x120/0x120
[  181.955836]  [<ffffffff8140b4f0>] ? gs_change+0xb/0xb
[  181.955839] Code: 80 00 00 00 00 48 83 c4 08 5b 5d c3 90 48 89 ef be 20 00 00 00 e8 73 a2 ff ff 
48 85 c0 48 89 c7 74 d7 48 89 83 d8 00 00 00 eb 8d <0f> 0b eb fe 48 8b 00 48 85 c0 0f 84 67 ff ff ff 
48 8b 40 50 48
[  181.955879] RIP  [<ffffffff812ad4ee>] scsi_setup_fs_cmnd+0xae/0xf0
[  181.955887]  RSP <ffff88041bfdbbe0>
[  181.955892] ---[ end trace 56499f30ff553488 ]---
[  181.955896] Kernel panic - not syncing: Fatal exception
[  181.955902] Pid: 1422, comm: md10_raid10 Tainted: G      D     3.1.0-rc9-00152-g3900b5a-dirty #6
[  181.955906] Call Trace:
[  181.955913]  [<ffffffff81406f69>] ? panic+0x92/0x193
[  181.955920]  [<ffffffff81035451>] ? kmsg_dump+0x41/0xf0
[  181.955929]  [<ffffffff8100504d>] ? oops_end+0x8d/0xa0
[  181.955936]  [<ffffffff81002e34>] ? do_invalid_op+0x84/0xa0
[  181.955943]  [<ffffffff812ad4ee>] ? scsi_setup_fs_cmnd+0xae/0xf0
[  181.955952]  [<ffffffff811d69ae>] ? cfq_set_request+0x15e/0x3b0
[  181.955958]  [<ffffffff8140b375>] ? invalid_op+0x15/0x20
[  181.955966]  [<ffffffff812ad4ee>] ? scsi_setup_fs_cmnd+0xae/0xf0
[  181.955972]  [<ffffffff812b7fec>] ? sd_prep_fn+0x15c/0xa50
[  181.955979]  [<ffffffff811c8c04>] ? blk_peek_request+0xb4/0x1d0
[  181.955986]  [<ffffffff812aca10>] ? scsi_request_fn+0x50/0x4a0
[  181.955993]  [<ffffffff811c95b8>] ? blk_flush_plug_list+0x188/0x210
[  181.956001]  [<ffffffff811c964b>] ? blk_finish_plug+0xb/0x30
[  181.956007]  [<ffffffff812fa768>] ? raid10d+0x908/0xb50
[  181.956013]  [<ffffffff81041183>] ? lock_timer_base+0x33/0x70
[  181.956021]  [<ffffffff814082b5>] ? schedule_timeout+0x1c5/0x230
[  181.956028]  [<ffffffff8130e57f>] ? md_thread+0x10f/0x140
[  181.956035]  [<ffffffff81050260>] ? wake_up_bit+0x40/0x40
[  181.956041]  [<ffffffff8130e470>] ? md_register_thread+0x100/0x100
[  181.956047]  [<ffffffff8130e470>] ? md_register_thread+0x100/0x100
[  181.956054]  [<ffffffff8104fe06>] ? kthread+0x96/0xa0
[  181.956060]  [<ffffffff8140b4f4>] ? kernel_thread_helper+0x4/0x10
[  181.956068]  [<ffffffff8104fd70>] ? kthread_worker_fn+0x120/0x120
[  181.956075]  [<ffffffff8140b4f0>] ? gs_change+0xb/0xb
[  181.958475] Rebooting in 10 seconds..

Re: Bcache explodes when trying to attach

[Kent Overstreet]

Doh, I just keep breaking stuff.

There are unfortunately known issues with running on top of dm/md -
they are high on my list but I've had a lot on my plate lately =/

Worst part of the md/dm issues are that passthrough mode is affected.
Apologies for having to find out the hard way.

Thanks for the heads up about the cgroup issue. I'm gonna post a new
version on lkml just as soon as I have time to finish the md/dm stuff
and thoroughly test it myself.

On Sat, Oct 15, 2011 at 5:59 AM, Brad Campbell
<lists2009-+nnirC7rrGZibQn6LdNjmg@public.gmane.org> wrote:
> On 15/10/11 13:43, Brad Campbell wrote:
>>
>> I'm trying bcache merged with linus' git head (-rc9). I suppose I should
>> really try it with a vanilla bcache-dev tree.
>>
>> Anyway, I can register the cache and backing device but when I try and
>> attach the cache set to the backing device this happens :
>
> Ok, so the build was broken in some odd way. Turns out the latest git does
> not build unless you have cgroups enabled (which by default I don't).
>
> This came from the same scenario using a vanilla bcache git clone..
>
> [  162.412296] bio: create slab <bio-2> at 2
> [  162.441711] bcache: journal entries 3-4 missing! (replaying 2-4)
> [  162.441805] bcache: journal replay done, 0 keys in 2 entries, seq 2-4
> [  181.955480] md: resync of RAID array md10
> [  181.955526] ------------[ cut here ]------------
> [  181.955533] kernel BUG at drivers/scsi/scsi_lib.c:1152!
> [  181.955539] invalid opcode: 0000 [#1] SMP
> [  181.955546] CPU 1
> [  181.955549] Modules linked in: nfs ipt_MASQUERADE xt_tcpudp
> iptable_filter iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack
> nf_defrag_ipv4 ip_tables x_tables deflate zlib_deflate des_generic cbc ecb
> crypto_blkcipher sha1_generic md5 hmac crypto_hash cryptomgr aead
> crypto_algapi af_key fuse w83627ehf hwmon_vid netconsole configfs vhost_net
> powernow_k8 mperf kvm_amd kvm xhci_hcd i2c_piix4 k10temp ohci_hcd ehci_hcd
> usbcore ahci libahci atl1c megaraid_sas [last unloaded: scsi_wait_scan]
> [  181.955600]
> [  181.955606] Pid: 1422, comm: md10_raid10 Not tainted
> 3.1.0-rc9-00152-g3900b5a-dirty #6 To Be Filled By O.E.M. To Be Filled By
> O.E.M./890GX Extreme4 R2.0
> [  181.955616] RIP: 0010:[<ffffffff812ad4ee>]  [<ffffffff812ad4ee>]
> scsi_setup_fs_cmnd+0xae/0xf0
> [  181.955631] RSP: 0018:ffff88041bfdbbe0  EFLAGS: 00010046
> [  181.955636] RAX: 0000000000000000 RBX: ffff88041c4d3830 RCX:
> 0000000000001000
> [  181.955641] RDX: 0000000000000000 RSI: ffff88041c4d3830 RDI:
> ffff88041c754800
> [  181.955645] RBP: ffff88041c754800 R08: 0000000000000000 R09:
> 0000000000000001
> [  181.955650] R10: 4080000000000000 R11: 0000000000000000 R12:
> ffff88041c754800
> [  181.955654] R13: 0000000000000808 R14: ffff88041c754848 R15:
> ffff88041c3cbc00
> [  181.955661] FS:  00007fc823617700(0000) GS:ffff88042fc40000(0000)
> knlGS:0000000000000000
> [  181.955668] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  181.955672] CR2: ffffffffff600400 CR3: 00000003ffe02000 CR4:
> 00000000000006e0
> [  181.955677] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [  181.955681] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [  181.955687] Process md10_raid10 (pid: 1422, threadinfo ffff88041bfda000,
> task ffff88041c1bcb00)
> [  181.955691] Stack:
> [  181.955693]  0000000000000000 ffff88041c4d3830 ffff88041bd83c30
> ffffffff812b7fec
> [  181.955701]  01ff88041c755000 ffff880400000001 ffff880400001000
> 0000000000000000
> [  181.955707]  ffff88041c4d3830 ffff88041c4d3830 ffff88041c4d3830
> ffff88041bd83c30
> [  181.955714] Call Trace:
> [  181.955723]  [<ffffffff812b7fec>] ? sd_prep_fn+0x15c/0xa50
> [  181.955732]  [<ffffffff811c8c04>] ? blk_peek_request+0xb4/0x1d0
> [  181.955739]  [<ffffffff812aca10>] ? scsi_request_fn+0x50/0x4a0
> [  181.955747]  [<ffffffff811c95b8>] ? blk_flush_plug_list+0x188/0x210
> [  181.955755]  [<ffffffff811c964b>] ? blk_finish_plug+0xb/0x30
> [  181.955762]  [<ffffffff812fa768>] ? raid10d+0x908/0xb50
> [  181.955770]  [<ffffffff81041183>] ? lock_timer_base+0x33/0x70
> [  181.955779]  [<ffffffff814082b5>] ? schedule_timeout+0x1c5/0x230
> [  181.955786]  [<ffffffff8130e57f>] ? md_thread+0x10f/0x140
> [  181.955795]  [<ffffffff81050260>] ? wake_up_bit+0x40/0x40
> [  181.955801]  [<ffffffff8130e470>] ? md_register_thread+0x100/0x100
> [  181.955807]  [<ffffffff8130e470>] ? md_register_thread+0x100/0x100
> [  181.955814]  [<ffffffff8104fe06>] ? kthread+0x96/0xa0
> [  181.955821]  [<ffffffff8140b4f4>] ? kernel_thread_helper+0x4/0x10
> [  181.955829]  [<ffffffff8104fd70>] ? kthread_worker_fn+0x120/0x120
> [  181.955836]  [<ffffffff8140b4f0>] ? gs_change+0xb/0xb
> [  181.955839] Code: 80 00 00 00 00 48 83 c4 08 5b 5d c3 90 48 89 ef be 20
> 00 00 00 e8 73 a2 ff ff 48 85 c0 48 89 c7 74 d7 48 89 83 d8 00 00 00 eb 8d
> <0f> 0b eb fe 48 8b 00 48 85 c0 0f 84 67 ff ff ff 48 8b 40 50 48
> [  181.955879] RIP  [<ffffffff812ad4ee>] scsi_setup_fs_cmnd+0xae/0xf0
> [  181.955887]  RSP <ffff88041bfdbbe0>
> [  181.955892] ---[ end trace 56499f30ff553488 ]---
> [  181.955896] Kernel panic - not syncing: Fatal exception
> [  181.955902] Pid: 1422, comm: md10_raid10 Tainted: G      D
> 3.1.0-rc9-00152-g3900b5a-dirty #6
> [  181.955906] Call Trace:
> [  181.955913]  [<ffffffff81406f69>] ? panic+0x92/0x193
> [  181.955920]  [<ffffffff81035451>] ? kmsg_dump+0x41/0xf0
> [  181.955929]  [<ffffffff8100504d>] ? oops_end+0x8d/0xa0
> [  181.955936]  [<ffffffff81002e34>] ? do_invalid_op+0x84/0xa0
> [  181.955943]  [<ffffffff812ad4ee>] ? scsi_setup_fs_cmnd+0xae/0xf0
> [  181.955952]  [<ffffffff811d69ae>] ? cfq_set_request+0x15e/0x3b0
> [  181.955958]  [<ffffffff8140b375>] ? invalid_op+0x15/0x20
> [  181.955966]  [<ffffffff812ad4ee>] ? scsi_setup_fs_cmnd+0xae/0xf0
> [  181.955972]  [<ffffffff812b7fec>] ? sd_prep_fn+0x15c/0xa50
> [  181.955979]  [<ffffffff811c8c04>] ? blk_peek_request+0xb4/0x1d0
> [  181.955986]  [<ffffffff812aca10>] ? scsi_request_fn+0x50/0x4a0
> [  181.955993]  [<ffffffff811c95b8>] ? blk_flush_plug_list+0x188/0x210
> [  181.956001]  [<ffffffff811c964b>] ? blk_finish_plug+0xb/0x30
> [  181.956007]  [<ffffffff812fa768>] ? raid10d+0x908/0xb50
> [  181.956013]  [<ffffffff81041183>] ? lock_timer_base+0x33/0x70
> [  181.956021]  [<ffffffff814082b5>] ? schedule_timeout+0x1c5/0x230
> [  181.956028]  [<ffffffff8130e57f>] ? md_thread+0x10f/0x140
> [  181.956035]  [<ffffffff81050260>] ? wake_up_bit+0x40/0x40
> [  181.956041]  [<ffffffff8130e470>] ? md_register_thread+0x100/0x100
> [  181.956047]  [<ffffffff8130e470>] ? md_register_thread+0x100/0x100
> [  181.956054]  [<ffffffff8104fe06>] ? kthread+0x96/0xa0
> [  181.956060]  [<ffffffff8140b4f4>] ? kernel_thread_helper+0x4/0x10
> [  181.956068]  [<ffffffff8104fd70>] ? kthread_worker_fn+0x120/0x120
> [  181.956075]  [<ffffffff8140b4f0>] ? gs_change+0xb/0xb
> [  181.958475] Rebooting in 10 seconds..
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Bcache explodes when trying to attach

[Brad Campbell]

On 16/10/11 13:08, Kent Overstreet wrote:
> Doh, I just keep breaking stuff.
>
> There are unfortunately known issues with running on top of dm/md -
> they are high on my list but I've had a lot on my plate lately =/
>
> Worst part of the md/dm issues are that passthrough mode is affected.
> Apologies for having to find out the hard way.
>
> Thanks for the heads up about the cgroup issue. I'm gonna post a new
> version on lkml just as soon as I have time to finish the md/dm stuff
> and thoroughly test it myself.
>
Not a hassle. I actually procured a "staging" machine to track down a long standing and annoying bug 
in netfilter, so as a consequence I have a machine sitting there with loads of hardware to allow me 
to beat on this stuff without having any consequences to crashes or corruption.

Happy to run some tests here under different conditions if you need wider coverage.

Re: Bcache explodes when trying to attach

[Kent Overstreet]

Ah, that's good to know. In that case - if you wanted to try it
without md - I don't _expect_ any issues, but then that's the point :)

Performance numbers would be awesome, if you got that far...

On Sat, Oct 15, 2011 at 10:15 PM, Brad Campbell
<lists2009-+nnirC7rrGZibQn6LdNjmg@public.gmane.org> wrote:
> On 16/10/11 13:08, Kent Overstreet wrote:
>>
>> Doh, I just keep breaking stuff.
>>
>> There are unfortunately known issues with running on top of dm/md -
>> they are high on my list but I've had a lot on my plate lately =/
>>
>> Worst part of the md/dm issues are that passthrough mode is affected.
>> Apologies for having to find out the hard way.
>>
>> Thanks for the heads up about the cgroup issue. I'm gonna post a new
>> version on lkml just as soon as I have time to finish the md/dm stuff
>> and thoroughly test it myself.
>>
> Not a hassle. I actually procured a "staging" machine to track down a long
> standing and annoying bug in netfilter, so as a consequence I have a machine
> sitting there with loads of hardware to allow me to beat on this stuff
> without having any consequences to crashes or corruption.
>
> Happy to run some tests here under different conditions if you need wider
> coverage.
>
>

Re: Bcache explodes when trying to attach

[Brad Campbell]

On 16/10/11 13:38, Kent Overstreet wrote:
> Ah, that's good to know. In that case - if you wanted to try it
> without md - I don't _expect_ any issues, but then that's the point :)
>
> Performance numbers would be awesome, if you got that far...

I've bumped up against another roadblock that puzzles me. Any insight 
would be much appreciated.

qemu fails to read from the device properly if it's opened with O_DIRECT 
on a bcache based block device.

If I just use ext4 on a normal partition it works fine.

Here are a couple of straces. Command lines are identical s/raid10/mnt/ 
for the second one. Both partitions contents are bit for bit identical 
rsync clones. Both ext4 and mounted with the same options. These were 
captured less than a minute apart, so for all intents and purposes they 
represent precisely the failure I'm seeing.

Failing on /dev/bcache0

29169 open("/raid10/VM/ubuntu_10.04LTS-zimbra.qcow2", 
O_RDONLY|O_NONBLOCK) = 9
29169 ioctl(9, CDROM_DRIVE_STATUS, 0x7fffffff) = -1 ENOTTY 
(Inappropriate ioctl for device)
29169 close(9)                          = 0
29169 open("/raid10/VM/ubuntu_10.04LTS-zimbra.qcow2", 
O_RDONLY|O_NONBLOCK) = 9
29169 ioctl(9, FDGETPRM, 0x7fff9a7cb9e0) = -1 ENOTTY (Inappropriate 
ioctl for device)
29169 close(9)                          = 0
29169 stat("/raid10/VM/ubuntu_10.04LTS-zimbra.qcow2", 
{st_mode=S_IFREG|0666, st_size=2058485760, ...}) = 0
29169 open("/raid10/VM/ubuntu_10.04LTS-zimbra.qcow2", 
O_RDWR|O_DIRECT|O_CLOEXEC) = 9
29169 mmap(NULL, 139264, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa3dea33000
29169 rt_sigprocmask(SIG_BLOCK, [USR2], NULL, 8) = 0
29169 signalfd(4294967295, [USR2], 8)   = 10
29169 fcntl(10, F_GETFD)                = 0
29169 fcntl(10, F_SETFD, FD_CLOEXEC)    = 0
29169 fcntl(10, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
29169 lseek(9, 0, SEEK_END)             = 2058485760
29169 pread(9, 0x7fa3dea34000, 512, 0)  = -1 EINVAL (Invalid argument)
29169 close(9)                          = 0

Working on /dev/sdg4

16269 open("/mnt/VM/ubuntu_10.04LTS-zimbra.qcow2", O_RDONLY|O_NONBLOCK) = 9
16269 ioctl(9, CDROM_DRIVE_STATUS, 0x7fffffff) = -1 ENOTTY 
(Inappropriate ioctl for device)
16269 close(9)                          = 0
16269 open("/mnt/VM/ubuntu_10.04LTS-zimbra.qcow2", O_RDONLY|O_NONBLOCK) = 9
16269 ioctl(9, FDGETPRM, 0x7fff8a3b1a40) = -1 ENOTTY (Inappropriate 
ioctl for device)
16269 close(9)                          = 0
16269 stat("/mnt/VM/ubuntu_10.04LTS-zimbra.qcow2", 
{st_mode=S_IFREG|0664, st_size=2058485760, ...}) = 0
16269 open("/mnt/VM/ubuntu_10.04LTS-zimbra.qcow2", 
O_RDWR|O_DIRECT|O_CLOEXEC) = 9
16269 mmap(NULL, 139264, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc626a46000
16269 rt_sigprocmask(SIG_BLOCK, [USR2], NULL, 8) = 0
16269 signalfd(4294967295, [USR2], 8)   = 10
16269 fcntl(10, F_GETFD)                = 0
16269 fcntl(10, F_SETFD, FD_CLOEXEC)    = 0
16269 fcntl(10, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
16269 lseek(9, 0, SEEK_END)             = 2058485760
16269 pread(9, 
"QFI\373\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20\0\0\0\5\0\0\0\0"..., 
512, 0) = 512
16269 pread(9, 
"\200\0\0\0\0\4\0\0\200\0\0\0\4&\0\0\200\0\0\0\4\205\0\0\0\0\0\0\0\0\0\0"..., 
512, 196608) = 512

Re: Bcache explodes when trying to attach

[Kent Overstreet]

Heh. I need to document stuff and change various defaults...

The open is O_DIRECT and the read is 512 bytes - it's failing because
it's smaller than the hardware sector size of the bcache device.

The block size you specify when you format the backing device gets
exported as the hardware sector size; the reason for that is to support
SSDs that have hardware sector sizes > 1 sector.

It can't just use the SSD's hw sector size directly because you could
bring up a bcache device in passthrough mode, attach a cache later
and... boom, you can't change that at runtime.

However, if you rerun make-bcache on the backing device with
--block-size 512, you shouldn't lose any data, you'll just have to
reattach it to the cache set (so make sure it's not in writeback mode
first).

On Mon, Oct 17, 2011 at 09:52:12PM +0800, Brad Campbell wrote:
> On 16/10/11 13:38, Kent Overstreet wrote:
> >Ah, that's good to know. In that case - if you wanted to try it
> >without md - I don't _expect_ any issues, but then that's the point :)
> >
> >Performance numbers would be awesome, if you got that far...
> 
> I've bumped up against another roadblock that puzzles me. Any
> insight would be much appreciated.
> 
> qemu fails to read from the device properly if it's opened with
> O_DIRECT on a bcache based block device.
> 
> If I just use ext4 on a normal partition it works fine.
> 
> Here are a couple of straces. Command lines are identical
> s/raid10/mnt/ for the second one. Both partitions contents are bit
> for bit identical rsync clones. Both ext4 and mounted with the same
> options. These were captured less than a minute apart, so for all
> intents and purposes they represent precisely the failure I'm
> seeing.
> 
> Failing on /dev/bcache0
> 
> 29169 open("/raid10/VM/ubuntu_10.04LTS-zimbra.qcow2",
> O_RDONLY|O_NONBLOCK) = 9
> 29169 ioctl(9, CDROM_DRIVE_STATUS, 0x7fffffff) = -1 ENOTTY
> (Inappropriate ioctl for device)
> 29169 close(9)                          = 0
> 29169 open("/raid10/VM/ubuntu_10.04LTS-zimbra.qcow2",
> O_RDONLY|O_NONBLOCK) = 9
> 29169 ioctl(9, FDGETPRM, 0x7fff9a7cb9e0) = -1 ENOTTY (Inappropriate
> ioctl for device)
> 29169 close(9)                          = 0
> 29169 stat("/raid10/VM/ubuntu_10.04LTS-zimbra.qcow2",
> {st_mode=S_IFREG|0666, st_size=2058485760, ...}) = 0
> 29169 open("/raid10/VM/ubuntu_10.04LTS-zimbra.qcow2",
> O_RDWR|O_DIRECT|O_CLOEXEC) = 9
> 29169 mmap(NULL, 139264, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa3dea33000
> 29169 rt_sigprocmask(SIG_BLOCK, [USR2], NULL, 8) = 0
> 29169 signalfd(4294967295, [USR2], 8)   = 10
> 29169 fcntl(10, F_GETFD)                = 0
> 29169 fcntl(10, F_SETFD, FD_CLOEXEC)    = 0
> 29169 fcntl(10, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
> 29169 lseek(9, 0, SEEK_END)             = 2058485760
> 29169 pread(9, 0x7fa3dea34000, 512, 0)  = -1 EINVAL (Invalid argument)
> 29169 close(9)                          = 0
> 
> Working on /dev/sdg4
> 
> 16269 open("/mnt/VM/ubuntu_10.04LTS-zimbra.qcow2", O_RDONLY|O_NONBLOCK) = 9
> 16269 ioctl(9, CDROM_DRIVE_STATUS, 0x7fffffff) = -1 ENOTTY
> (Inappropriate ioctl for device)
> 16269 close(9)                          = 0
> 16269 open("/mnt/VM/ubuntu_10.04LTS-zimbra.qcow2", O_RDONLY|O_NONBLOCK) = 9
> 16269 ioctl(9, FDGETPRM, 0x7fff8a3b1a40) = -1 ENOTTY (Inappropriate
> ioctl for device)
> 16269 close(9)                          = 0
> 16269 stat("/mnt/VM/ubuntu_10.04LTS-zimbra.qcow2",
> {st_mode=S_IFREG|0664, st_size=2058485760, ...}) = 0
> 16269 open("/mnt/VM/ubuntu_10.04LTS-zimbra.qcow2",
> O_RDWR|O_DIRECT|O_CLOEXEC) = 9
> 16269 mmap(NULL, 139264, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc626a46000
> 16269 rt_sigprocmask(SIG_BLOCK, [USR2], NULL, 8) = 0
> 16269 signalfd(4294967295, [USR2], 8)   = 10
> 16269 fcntl(10, F_GETFD)                = 0
> 16269 fcntl(10, F_SETFD, FD_CLOEXEC)    = 0
> 16269 fcntl(10, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
> 16269 lseek(9, 0, SEEK_END)             = 2058485760
> 16269 pread(9, "QFI\373\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20\0\0\0\5\0\0\0\0"...,
> 512, 0) = 512
> 16269 pread(9, "\200\0\0\0\0\4\0\0\200\0\0\0\4&\0\0\200\0\0\0\4\205\0\0\0\0\0\0\0\0\0\0"...,
> 512, 196608) = 512
>