Hello, 1 week ago I bought a new 2TB hard drive, created 1 partition on the whole disk, and created root and swap LVM volumes on it. I formatted root to btrfs with default options, except meta-data profile which I set to "single". I copied all my data to it and unplugged my old hard drives. It worked for a week. Today I installed another 2TB hard drive, created LVM volumes as before, and added to my root filesystem. I started balance with data and metadata conversion to raid1. I left it doing its job, and returned few hours later. When I returned hard disks were idle, screen would not unlock, and I could not log in. I had to reset it. After reset it won''t mount. I booted the computer from a live-cd. It has an ancient kernel, so I installed qemu and captured the oops on the current version compiled from git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git: # mount /dev/hdb /mnt/test -odevice=/dev/hdc device label root devid 2 transid 56098 /dev/hdc device label root devid 1 transid 56098 /dev/hdb btrfs: disk space caching is enabled ------------[ cut here ]------------ WARNING: at fs/btrfs/delayed-ref.c:454 update_existing_ref+0xd2/0x110() Hardware name: Bochs Pid: 309, comm: exe Not tainted 3.6.0+ #1 Call Trace: [<c101f4b8>] warn_slowpath_common+0x68/0xa0 [<c1171362>] ? update_existing_ref+0xd2/0x110 [<c1171362>] ? update_existing_ref+0xd2/0x110 [<c101f59b>] warn_slowpath_null+0x1b/0x20 [<c1171362>] update_existing_ref+0xd2/0x110 [<c117185b>] add_delayed_tree_ref+0x12b/0x160 [<c11722d8>] btrfs_add_delayed_tree_ref+0xf8/0x180 [<c111d6f5>] btrfs_free_extent+0x125/0x1a0 [<c1174234>] replace_path+0x6d4/0x770 [<c1146457>] ? btrfs_get_token_64+0x57/0x110 [<c1178bdc>] merge_reloc_root+0x2ac/0x4f0 [<c1178f06>] merge_reloc_roots+0xe6/0x120 [<c1179ee4>] btrfs_recover_relocation+0x384/0x3f0 [<c112ecd5>] open_ctree+0x1695/0x1940 [<c1129270>] ? cleaner_kthread+0xb0/0xb0 [<c11a84dd>] ? strlcpy+0x1d/0x110 [<c1109b27>] btrfs_mount+0x677/0x850 [<c11a4bbd>] ? ida_get_new_above+0x1ed/0x220 [<c107ee60>] ? __kmalloc_track_caller+0x70/0x130 [<c1098712>] ? alloc_vfsmnt+0x62/0x100 [<c108388c>] mount_fs+0x1c/0xc0 [<c1098712>] ? alloc_vfsmnt+0x62/0x100 [<c1099314>] vfs_kern_mount+0x44/0xd0 [<c1099407>] do_kern_mount+0x37/0xf0 [<c109a804>] do_mount+0x3b4/0x700 [<c109abb6>] sys_mount+0x66/0xa0 [<c1221a45>] syscall_call+0x7/0xb ---[ end trace 0437071747fbcc24 ]--- ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent-tree.c:1772! invalid opcode: 0000 [#1] Pid: 309, comm: exe Tainted: G W 3.6.0+ #1 Bochs Bochs EIP: 0060:[<c1117aec>] EFLAGS: 00010297 CPU: 0 EIP is at insert_inline_extent_backref+0x13c/0x140 EAX: 00000000 EBX: 00000000 ECX: d742b0e0 EDX: 00000000 ESI: 00000000 EDI: 00000002 EBP: d790dabc ESP: d790da68 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 CR0: 8005003b CR2: 08053000 CR3: 178fd000 CR4: 00000690 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process exe (pid: 309, ti=d790c000 task=d7902fa0 task.ti=d790c000) Stack: d790daac 90e31000 00000125 00001000 00000000 1be77000 000000c8 00000000 00000000 00000002 00000000 00000000 00000000 00000001 d742b0e0 d78dec00 d74233c0 00000ecb 00000125 d742b0e0 d722c000 d790db28 c1117b98 90e31000 Call Trace: [<c1117b98>] __btrfs_inc_extent_ref+0xa8/0x240 [<c111e2c1>] run_clustered_refs+0x501/0xaa0 [<c1172167>] ? btrfs_find_ref_cluster+0xd7/0x150 [<c112159e>] btrfs_run_delayed_refs+0x8e/0x250 [<c1130f1a>] __btrfs_end_transaction+0xaa/0x3b0 [<c113123d>] btrfs_end_transaction_throttle+0xd/0x10 [<c1178b72>] merge_reloc_root+0x242/0x4f0 [<c1178f06>] merge_reloc_roots+0xe6/0x120 [<c1179ee4>] btrfs_recover_relocation+0x384/0x3f0 [<c112ecd5>] open_ctree+0x1695/0x1940 [<c1129270>] ? cleaner_kthread+0xb0/0xb0 [<c11a84dd>] ? strlcpy+0x1d/0x110 [<c1109b27>] btrfs_mount+0x677/0x850 [<c11a4bbd>] ? ida_get_new_above+0x1ed/0x220 [<c107ee60>] ? __kmalloc_track_caller+0x70/0x130 [<c1098712>] ? alloc_vfsmnt+0x62/0x100 [<c108388c>] mount_fs+0x1c/0xc0 [<c1098712>] ? alloc_vfsmnt+0x62/0x100 [<c1099314>] vfs_kern_mount+0x44/0xd0 [<c1099407>] do_kern_mount+0x37/0xf0 [<c109a804>] do_mount+0x3b4/0x700 [<c109abb6>] sys_mount+0x66/0xa0 [<c1221a45>] syscall_call+0x7/0xb Code: 1c 89 44 24 04 8b 45 f0 89 54 24 08 8b 55 e8 89 04 24 8b 45 ec e8 15 f9 ff ff eb 8a 8d 76 00 81 ff ff 00 00 00 0f 87 59 ff ff ff <0f> 0b 66 90 55 89 e5 57 89 d7 56 53 83 ec 58 8b 5d 28 89 45 ec EIP: [<c1117aec>] insert_inline_extent_backref+0x13c/0x140 SS:ESP 0068:d790da68 ---[ end trace 0437071747fbcc25 ]--- Segmentation fault / # ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent-tree.c:1772! invalid opcode: 0000 [#2] Pid: 329, comm: btrfs-transacti Tainted: G D W 3.6.0+ #1 Bochs Bochs EIP: 0060:[<c1117aec>] EFLAGS: 00010297 CPU: 0 EIP is at insert_inline_extent_backref+0x13c/0x140 EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000002 EBP: d7207d88 ESP: d7207d34 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 CR0: 8005003b CR2: b77a8000 CR3: 178f9000 CR4: 00000690 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process btrfs-transacti (pid: 329, ti=d7206000 task=d794dc20 task.ti=d7206000) Stack: d7207d78 57175000 000000ef 00001000 00000000 1be77000 000000c8 00000000 00000000 00000002 00000000 00000000 00000000 00000001 d742b150 d78dec00 d7423420 0000098e 000000ef d742b150 d78de800 d7207df4 c1117b98 57175000 Call Trace: [<c1117b98>] __btrfs_inc_extent_ref+0xa8/0x240 [<c111e2c1>] run_clustered_refs+0x501/0xaa0 [<c1172167>] ? btrfs_find_ref_cluster+0xd7/0x150 [<c112159e>] btrfs_run_delayed_refs+0x8e/0x250 [<c1130571>] btrfs_commit_transaction+0x71/0x940 [<c107d66a>] ? kmem_cache_alloc+0x5a/0xf0 [<c113132e>] ? start_transaction+0xde/0x3d0 [<c1036b50>] ? abort_exclusive_wait+0x60/0x60 [<c11293d5>] transaction_kthread+0x165/0x1a0 [<c1129270>] ? cleaner_kthread+0xb0/0xb0 [<c10364ac>] kthread+0x6c/0x80 [<c1036440>] ? kthread_flush_work_fn+0x10/0x10 [<c1222416>] kernel_thread_helper+0x6/0xd Code: 1c 89 44 24 04 8b 45 f0 89 54 24 08 8b 55 e8 89 04 24 8b 45 ec e8 15 f9 ff ff eb 8a 8d 76 00 81 ff ff 00 00 00 0f 87 59 ff ff ff <0f> 0b 66 90 55 89 e5 57 89 d7 56 53 83 ec 58 8b 5d 28 89 45 ec EIP: [<c1117aec>] insert_inline_extent_backref+0x13c/0x140 SS:ESP 0068:d7207d34 ---[ end trace 0437071747fbcc26 ]--- Reported line is: 1772 BUG_ON(owner < BTRFS_FIRST_FREE_OBJECTID); btrfsck doesn''t find anything wrong with the FS: checking extents checking fs roots checking root refs found 814959656960 bytes used err is 0 total csum bytes: 788550204 total tree bytes: 7330582528 total fs tree bytes: 5939347456 btree space waste bytes: 1823524971 file data blocks allocated: 7249231036416 referenced 873999015936 Btrfs v0.20-rc1-56-g6cd836d I tried mounting with -orecovery, clean_cache, skip_balance, nothing helps. I can, however, mount it read-only. Other info about the fs: # btrfs fi show Label: ''root'' uuid: 8b7a0276-d331-478c-b829-7614f2e7dc6a Total devices 2 FS bytes used 758.99GB devid 2 size 1.81TB used 554.03GB path /dev/hdc devid 1 size 1.81TB used 766.04GB path /dev/hdb # btrfs fi df /mnt/test Data, RAID1: total=544.00GB, used=543.33GB Data: total=209.00GB, used=208.83GB System, RAID1: total=32.00MB, used=92.00KB System: total=4.00MB, used=20.00KB Metadata, RAID1: total=10.00GB, used=4.62GB Metadata: total=3.00GB, used=2.21GB Regards -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Piotr Pawłow
2013-Feb-04 07:41 UTC
Re: kernel BUG at fs/btrfs/extent-tree.c:1755 (was: 1772)
I also tried for-linus branch, looks like the same problem: # mount /dev/hdb -odevice=/dev/hdc /mnt/test device label root devid 2 transid 56098 /dev/hdc device label root devid 1 transid 56098 /dev/hdb btrfs: disk space caching is enabled ------------[ cut here ]------------ WARNING: at fs/btrfs/delayed-ref.c:454 update_existing_ref+0xd2/0x110() Hardware name: Bochs Pid: 305, comm: exe Not tainted 3.7.0+ #1 Call Trace: [<c10202b8>] warn_slowpath_common+0x68/0xa0 [<c1176712>] ? update_existing_ref+0xd2/0x110 [<c1176712>] ? update_existing_ref+0xd2/0x110 [<c102039b>] warn_slowpath_null+0x1b/0x20 [<c1176712>] update_existing_ref+0xd2/0x110 [<c1176c0b>] add_delayed_tree_ref+0x12b/0x160 [<c1177688>] btrfs_add_delayed_tree_ref+0xf8/0x180 [<c111fbd5>] btrfs_free_extent+0x125/0x1a0 [<c11795e4>] replace_path+0x6d4/0x770 [<c114a037>] ? btrfs_get_token_64+0x57/0x110 [<c117df43>] merge_reloc_root+0x293/0x4e0 [<c117e276>] merge_reloc_roots+0xe6/0x120 [<c117f2b4>] btrfs_recover_relocation+0x384/0x3f0 [<c1131fde>] open_ctree+0x18be/0x1a60 [<c112c2d0>] ? btrfs_alloc_root+0x40/0x40 [<c11b09dd>] ? strlcpy+0x1d/0x110 [<c110c4b7>] btrfs_mount+0x677/0x850 [<c11ad4ad>] ? ida_get_new_above+0x1ed/0x220 [<c1081310>] ? __kmalloc_track_caller+0x70/0x130 [<c109a4a2>] ? alloc_vfsmnt+0x62/0x100 [<c1085acc>] mount_fs+0x1c/0xc0 [<c109a4a2>] ? alloc_vfsmnt+0x62/0x100 [<c109b0a4>] vfs_kern_mount+0x44/0xd0 [<c109b197>] do_kern_mount+0x37/0xf0 [<c109c594>] do_mount+0x3b4/0x700 [<c109c946>] sys_mount+0x66/0xa0 [<c122b2f5>] syscall_call+0x7/0xb ---[ end trace 4c5c7c49fa61dfab ]--- ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent-tree.c:1755! invalid opcode: 0000 [#1] Pid: 305, comm: exe Tainted: G W 3.7.0+ #1 Bochs Bochs EIP: 0060:[<c111a7fc>] EFLAGS: 00010297 CPU: 0 EIP is at insert_inline_extent_backref+0x13c/0x140 EAX: 00000000 EBX: 00000000 ECX: d751c070 EDX: 00000000 ESI: 00000000 EDI: 00000002 EBP: d790dabc ESP: d790da68 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 CR0: 8005003b CR2: 08053000 CR3: 178e4000 CR4: 00000690 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process exe (pid: 305, ti=d790c000 task=d7902fa0 task.ti=d790c000) Stack: d790daac 90e31000 00000125 00001000 00000000 1be77000 000000c8 00000000 00000000 00000002 00000000 00000000 00000000 00000001 d751c070 d78dec00 d74233c0 00000ecb 00000125 d751c070 d7230000 d790db28 c111a8a8 90e31000 Call Trace: [<c111a8a8>] __btrfs_inc_extent_ref+0xa8/0x240 [<c11207a1>] run_clustered_refs+0x501/0xb00 [<c1177517>] ? btrfs_find_ref_cluster+0xd7/0x150 [<c11244ce>] btrfs_run_delayed_refs+0x8e/0x250 [<c113419a>] __btrfs_end_transaction+0xaa/0x3b0 [<c11344bd>] btrfs_end_transaction_throttle+0xd/0x10 [<c117dee6>] merge_reloc_root+0x236/0x4e0 [<c117e276>] merge_reloc_roots+0xe6/0x120 [<c117f2b4>] btrfs_recover_relocation+0x384/0x3f0 [<c1131fde>] open_ctree+0x18be/0x1a60 [<c112c2d0>] ? btrfs_alloc_root+0x40/0x40 [<c11b09dd>] ? strlcpy+0x1d/0x110 [<c110c4b7>] btrfs_mount+0x677/0x850 [<c11ad4ad>] ? ida_get_new_above+0x1ed/0x220 [<c1081310>] ? __kmalloc_track_caller+0x70/0x130 [<c109a4a2>] ? alloc_vfsmnt+0x62/0x100 [<c1085acc>] mount_fs+0x1c/0xc0 [<c109a4a2>] ? alloc_vfsmnt+0x62/0x100 [<c109b0a4>] vfs_kern_mount+0x44/0xd0 [<c109b197>] do_kern_mount+0x37/0xf0 [<c109c594>] do_mount+0x3b4/0x700 [<c109c946>] sys_mount+0x66/0xa0 [<c122b2f5>] syscall_call+0x7/0xb Code: 1c 89 44 24 04 8b 45 f0 89 54 24 08 8b 55 e8 89 04 24 8b 45 ec e8 15 f9 ff ff eb 8a 8d 76 00 81 ff ff 00 00 00 0f 87 59 ff ff ff <0f> 0b 66 90 55 89 e5 57 89 d7 56 53 83 ec 58 8b 5d 28 89 45 ec EIP: [<c111a7fc>] insert_inline_extent_backref+0x13c/0x140 SS:ESP 0068:d790da68 ---[ end trace 4c5c7c49fa61dfac ]--- Segmentation fault / # ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent-tree.c:1755! invalid opcode: 0000 [#2] Pid: 326, comm: btrfs-transacti Tainted: G D W 3.7.0+ #1 Bochs Bochs EIP: 0060:[<c111a7fc>] EFLAGS: 00010297 CPU: 0 EIP is at insert_inline_extent_backref+0x13c/0x140 EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000002 EBP: d720bd40 ESP: d720bcec DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 CR0: 8005003b CR2: b7779000 CR3: 178fa000 CR4: 00000690 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process btrfs-transacti (pid: 326, ti=d720a000 task=d7208000 task.ti=d720a000) Stack: d720bd30 57175000 000000ef 00001000 00000000 1be77000 000000c8 00000000 00000000 00000002 00000000 00000000 00000000 00000001 d751c4d0 d78dec00 d7423420 0000098e 000000ef d751c4d0 d78de800 d720bdac c111a8a8 57175000 Call Trace: [<c111a8a8>] __btrfs_inc_extent_ref+0xa8/0x240 [<c11207a1>] run_clustered_refs+0x501/0xb00 [<c1177517>] ? btrfs_find_ref_cluster+0xd7/0x150 [<c11244ce>] btrfs_run_delayed_refs+0x8e/0x250 [<c1133809>] btrfs_commit_transaction+0x69/0x920 [<c1040e80>] ? update_curr.constprop.48+0x50/0xa0 [<c107fc8a>] ? kmem_cache_alloc+0x5a/0xf0 [<c11345be>] ? start_transaction+0xee/0x3e0 [<c1134540>] ? start_transaction+0x70/0x3e0 [<c1037a80>] ? abort_exclusive_wait+0x60/0x60 [<c112c435>] transaction_kthread+0x165/0x1a0 [<c112c2d0>] ? btrfs_alloc_root+0x40/0x40 [<c103726e>] kthread+0x8e/0xa0 [<c122b717>] ret_from_kernel_thread+0x1b/0x28 [<c10371e0>] ? __kthread_parkme+0x60/0x60 Code: 1c 89 44 24 04 8b 45 f0 89 54 24 08 8b 55 e8 89 04 24 8b 45 ec e8 15 f9 ff ff eb 8a 8d 76 00 81 ff ff 00 00 00 0f 87 59 ff ff ff <0f> 0b 66 90 55 89 e5 57 89 d7 56 53 83 ec 58 8b 5d 28 89 45 ec EIP: [<c111a7fc>] insert_inline_extent_backref+0x13c/0x140 SS:ESP 0068:d720bcec ---[ end trace 4c5c7c49fa61dfad ]--- fs/btrfs/extent-tree.c:1755 is, again: 1755 BUG_ON(owner < BTRFS_FIRST_FREE_OBJECTID); Regards -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Piotr Pawłow
2013-Feb-04 09:16 UTC
Re: kernel BUG at fs/btrfs/extent-tree.c:1755 (was: 1772)
Hello, situation update: I realized I haven''t tried "nospace_cache" yet, even though I tried "clear_cache". "clear cache" doesn''t help at all. On the other hand, with "nospace_cache": # mount /dev/hdb -odevice=/dev/hdc,nospace_cache /mnt/test device label root devid 2 transid 56099 /dev/hdc device label root devid 1 transid 56099 /dev/hdb btrfs: disabling disk space caching btrfs: unlinked 1 orphans / # btrfs: continuing balance btrfs: relocating block group 776713797632 flags 4 It successfully mounts rw and continues the balance. I''m still doing it all on qemu with "-snapshot" option, to keep HD contents unmodified. Now the question is: should I try to mount it "nospace_cache" for real, try to keep using it and see what happens, or is anyone interested in debugging this problem further before I potentially destroy the "evidence"? Regards -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Feb 03, 2013 at 04:37:58PM -0700, "Piotr Pawłow" wrote:> Hello, > > 1 week ago I bought a new 2TB hard drive, created 1 partition on the whole > disk, and created root and swap LVM volumes on it. I formatted root to > btrfs with default options, except meta-data profile which I set to > "single". I copied all my data to it and unplugged my old hard drives. It > worked for a week. > > Today I installed another 2TB hard drive, created LVM volumes as before, > and added to my root filesystem. I started balance with data and metadata > conversion to raid1. I left it doing its job, and returned few hours > later. When I returned hard disks were idle, screen would not unlock, and > I could not log in. I had to reset it. > > After reset it won''t mount. I booted the computer from a live-cd. It has > an ancient kernel, so I installed qemu and captured the oops on the > current version compiled from > git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git: >Ok good you have a git tree. Can you run these commands git remote-add josef \ git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git git fetch josef git co josef/piotr and then build that and run that. It will spit out some debug stuff when it mounts before it panics, can you capture all the output and reply to this email with it? Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> mounts before it panics, can you capture all the output and reply to this > email > with it? Thanks,I''m sorry, I could not keep it longer in that state. I used btrfs-image to create metadata image from both disks, then let it run without space cache. Unfortunately, when I run qemu with these images: # btrfs fi show Label: ''root'' uuid: 8b7a0276-d331-478c-b829-7614f2e7dc6a Total devices 2 FS bytes used 758.99GB devid 2 size 1.81TB used 554.03GB path /dev/hdc devid 1 size 1.81TB used 766.04GB path /dev/hdb Looks good, let''s try to mount: # mount /dev/hdb /mnt/test -odevice=/dev/hdc,ro device label root devid 2 transid 56099 /dev/hdc device label root devid 1 transid 56099 /dev/hdb btrfs: disk space caching is enabled ------------[ cut here ]------------ kernel BUG at fs/btrfs/volumes.c:4586! invalid opcode: 0000 [#1] Pid: 307, comm: exe Not tainted 3.7.0+ #3 Bochs Bochs EIP: 0060:[<c115d369>] EFLAGS: 00010286 CPU: 0 EIP is at btrfs_rmap_block+0x389/0x3d0 EAX: c5c00000 EBX: 00000000 ECX: d742d000 EDX: c5c00000 ESI: 00000000 EDI: 00000000 EBP: d7933c94 ESP: d7933c34 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 CR0: 8005003b CR2: 08053000 CR3: 1790c000 CR4: 00000690 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process exe (pid: 307, ti=d7932000 task=d7902fa0 task.ti=d7932000) Stack: 00000001 00000000 d7430b80 d7933d42 00000019 00000006 d742d000 c5c00000 00000000 00001000 000000c8 d7902fa0 00000000 00000000 00000000 d7933cac c1154ede d7933c84 c1167fb7 d742d0e0 d7933c94 00010000 00000000 00000000 Call Trace: [<c1154ede>] ? map_private_extent_buffer+0x5e/0xe0 [<c1167fb7>] ? btrfs_set_lock_blocking_rw+0x57/0x90 [<c111b4c2>] exclude_super_stripes.isra.67+0x82/0x170 [<c11536a1>] ? free_extent_buffer+0x21/0x70 [<c1124401>] btrfs_read_block_groups+0x2e1/0x610 [<c1131f12>] open_ctree+0x12f2/0x1b70 [<c11b1c7d>] ? strlcpy+0x1d/0x110 [<c110c4b7>] btrfs_mount+0x677/0x850 [<c11ae74d>] ? ida_get_new_above+0x1ed/0x220 [<c1081310>] ? __kmalloc_track_caller+0x70/0x130 [<c109a4a2>] ? alloc_vfsmnt+0x62/0x100 [<c1085acc>] mount_fs+0x1c/0xc0 [<c109a4a2>] ? alloc_vfsmnt+0x62/0x100 [<c109b0a4>] vfs_kern_mount+0x44/0xd0 [<c109b197>] do_kern_mount+0x37/0xf0 [<c109c594>] do_mount+0x3b4/0x700 [<c109c946>] sys_mount+0x66/0xa0 [<c122c595>] syscall_call+0x7/0xb Code: fe ff ff 0f 85 2d ff ff ff 31 ff e9 0f ff ff ff 66 90 89 c8 31 d2 f7 f6 89 c1 e9 1f fd ff ff c7 45 e8 00 00 00 00 e9 27 ff ff ff <0f> 0b ba 07 12 00 00 b8 50 f8 28 c1 89 4d b0 e8 03 30 ec ff 8b EIP: [<c115d369>] btrfs_rmap_block+0x389/0x3d0 SS:ESP 0068:d7933c34 ---[ end trace 78658a7dd47c6f96 ]--- It fails in a different way :( 4586 BUG_ON(!em || em->start != chunk_start); (kernel from btrfs-next/piotr) As to the original FS, balance kept running until the end and finished without errors. I''ll try to run some more balance operations to see if it happens again. Thanks for your support. Regards -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Feb 05, 2013 at 01:55:17AM -0700, "Piotr Pawłow" wrote:> > mounts before it panics, can you capture all the output and reply to this > > email > > with it? Thanks, > > I''m sorry, I could not keep it longer in that state. I used btrfs-image to > create metadata image from both disks, then let it run without space > cache. > > Unfortunately, when I run qemu with these images: >Yeah you can''t mount images, we clear out the chunk tree so nothing works. Let me know if you run into any problems in the future. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Piotr Pawłow
2013-Feb-10 00:32 UTC
btrfs and LVM snapshots (Re: kernel BUG at fs/btrfs/extent-tree.c:1772)
Hello,> Yeah you can''t mount images, we clear out the chunk tree so nothing works. > Let me know if you run into any problems in the future. Thanks,That''s surprising, I haven''t seen it mentioned anywhere. With any other filesystem I could use an LVM snapshot to save the original state, but with a multi-device btrfs it would be very risky. Origin and snapshot volumes could easily get mixed up by kernel and tools. I tried that in qemu, and I''ve seen btrfs happily mount 1 origin and 1 snapshot device as a single FS. And then I''ve seen it mount both origin devices, even though one of them had old content. Naturally it complained a lot about bad checksums. Is there any way to avoid such mix-ups? To somehow mark devices so that btrfs would know these devices belong together? Regards -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Goffredo Baroncelli
2013-Feb-10 13:28 UTC
Re: btrfs and LVM snapshots (Re: kernel BUG at fs/btrfs/extent-tree.c:1772)
On 02/10/2013 01:32 AM, Piotr Pawłow wrote:> Hello, >> Yeah you can''t mount images, we clear out the chunk tree so >> nothing works. Let me know if you run into any problems in the >> future. Thanks, > > That''s surprising, I haven''t seen it mentioned anywhere. > > With any other filesystem I could use an LVM snapshot to save the > original state, but with a multi-device btrfs it would be very > risky. Origin and snapshot volumes could easily get mixed up by > kernel and tools. > > I tried that in qemu, and I''ve seen btrfs happily mount 1 origin and > 1 snapshot device as a single FS. And then I''ve seen it mount both > origin devices, even though one of them had old content. Naturally > it complained a lot about bad checksums.I can confirm that, even with a single-device btrfs filesystem. However I am curious why you want to use the lvm snapshot capability instead of the btrfs one.> > Is there any way to avoid such mix-ups? To somehow mark devices so > that btrfs would know these devices belong together?Btrfs assume that every device has an "unique" uuid. However when a device is snapshotted it uuid is copied too, so it is not unique any more. This is the reason of the btrfs confusing.> Regards -- To unsubscribe from this list: send the line "unsubscribe > linux-btrfs" in the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >-- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ss -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Piotr Pawłow
2013-Feb-12 21:39 UTC
Re: btrfs and LVM snapshots (Re: kernel BUG at fs/btrfs/extent-tree.c:1772)
> I can confirm that, even with a single-device btrfs filesystem. However > I am curious why you want to use the lvm snapshot capability instead of > the btrfs one.You can''t use btrfs snapshots on a broken FS. LVM snapshots would be useful to save the original state, before any potentially destructive repair attempts, and for further analysis. Regards -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html