kernel BUG at fs/btrfs/extent-tree.c:1772

kernel BUG at fs/btrfs/extent-tree.c:1772

["Piotr Pawłow"]

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

Re: kernel BUG at fs/btrfs/extent-tree.c:1755 (was: 1772)

["Piotr Pawłow"]

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

Re: kernel BUG at fs/btrfs/extent-tree.c:1755 (was: 1772)

["Piotr Pawłow"]

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

Re: kernel BUG at fs/btrfs/extent-tree.c:1772

[Josef Bacik]

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

Re: kernel BUG at fs/btrfs/extent-tree.c:1772

["Piotr Pawłow"]

> 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

Re: kernel BUG at fs/btrfs/extent-tree.c:1772

[Josef Bacik]

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

btrfs and LVM snapshots (Re: kernel BUG at fs/btrfs/extent-tree.c:1772)

[Piotr Pawłow]

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

Re: btrfs and LVM snapshots (Re: kernel BUG at fs/btrfs/extent-tree.c:1772)

[Goffredo Baroncelli]

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

Re: btrfs and LVM snapshots (Re: kernel BUG at fs/btrfs/extent-tree.c:1772)

[Piotr Pawłow]

> 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