* Btrfs resize seems to deadlock
@ 2018-10-20 2:05 Andrew Nelson
2018-10-20 20:23 ` Liu Bo
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Nelson @ 2018-10-20 2:05 UTC (permalink / raw)
To: linux-btrfs
I am having an issue with btrfs resize in Fedora 28. I am attempting
to enlarge my Btrfs partition. Every time I run "btrfs filesystem
resize max $MOUNT", the command runs for a few minutes and then hangs
forcing the system to be reset. I am not sure what the state of the
filesystem really is at this point. Btrfs usage does report the
correct size for after resizing. Details below:
$ sudo btrfs filesystem usage $MOUNT
Overall:
Device size: 90.96TiB
Device allocated: 72.62TiB
Device unallocated: 18.33TiB
Device missing: 0.00B
Used: 72.62TiB
Free (estimated): 18.34TiB (min: 9.17TiB)
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 24.11MiB)
Data,single: Size:72.46TiB, Used:72.45TiB
$MOUNT 72.46TiB
Metadata,DUP: Size:86.00GiB, Used:84.96GiB
$MOUNT 172.00GiB
System,DUP: Size:40.00MiB, Used:7.53MiB
$MOUNT 80.00MiB
Unallocated:
$MOUNT 18.33TiB
$ uname -a
Linux localhost.localdomain 4.18.14-200.fc28.x86_64 #1 SMP Mon Oct 15
13:16:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
btrfs-transacti D 0 2501 2 0x80000000
Call Trace:
? __schedule+0x253/0x860
schedule+0x28/0x80
btrfs_commit_transaction+0x7aa/0x8b0 [btrfs]
? kmem_cache_alloc+0x166/0x1d0
? join_transaction+0x22/0x3e0 [btrfs]
? finish_wait+0x80/0x80
transaction_kthread+0x155/0x170 [btrfs]
? btrfs_cleanup_transaction+0x550/0x550 [btrfs]
kthread+0x112/0x130
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x35/0x40
btrfs D 0 2504 2502 0x00000002
Call Trace:
? __schedule+0x253/0x860
schedule+0x28/0x80
btrfs_tree_read_lock+0x8e/0x120 [btrfs]
? finish_wait+0x80/0x80
btrfs_read_lock_root_node+0x2f/0x40 [btrfs]
btrfs_search_slot+0xf6/0x9f0 [btrfs]
? evict_refill_and_join+0xd0/0xd0 [btrfs]
? inode_insert5+0x119/0x190
btrfs_lookup_inode+0x3a/0xc0 [btrfs]
? kmem_cache_alloc+0x166/0x1d0
btrfs_iget+0x113/0x690 [btrfs]
__lookup_free_space_inode+0xd8/0x150 [btrfs]
lookup_free_space_inode+0x5b/0xb0 [btrfs]
load_free_space_cache+0x7c/0x170 [btrfs]
? cache_block_group+0x72/0x3b0 [btrfs]
cache_block_group+0x1b3/0x3b0 [btrfs]
? finish_wait+0x80/0x80
find_free_extent+0x799/0x1010 [btrfs]
btrfs_reserve_extent+0x9b/0x180 [btrfs]
btrfs_alloc_tree_block+0x1b3/0x4f0 [btrfs]
__btrfs_cow_block+0x11d/0x500 [btrfs]
btrfs_cow_block+0xdc/0x180 [btrfs]
btrfs_search_slot+0x3bd/0x9f0 [btrfs]
btrfs_lookup_inode+0x3a/0xc0 [btrfs]
? kmem_cache_alloc+0x166/0x1d0
btrfs_update_inode_item+0x46/0x100 [btrfs]
cache_save_setup+0xe4/0x3a0 [btrfs]
btrfs_start_dirty_block_groups+0x1be/0x480 [btrfs]
btrfs_commit_transaction+0xcb/0x8b0 [btrfs]
? btrfs_release_path+0x13/0x80 [btrfs]
? btrfs_update_device+0x8d/0x1c0 [btrfs]
btrfs_ioctl_resize.cold.46+0xf4/0xf9 [btrfs]
btrfs_ioctl+0xa25/0x2cf0 [btrfs]
? tty_write+0x1fc/0x330
? do_vfs_ioctl+0xa4/0x620
do_vfs_ioctl+0xa4/0x620
ksys_ioctl+0x60/0x90
? ksys_write+0x4f/0xb0
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x5b/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fcdc0d78c57
Code: Bad RIP value.
RSP: 002b:00007ffdd1ee6cf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007ffdd1ee888a RCX: 00007fcdc0d78c57
RDX: 00007ffdd1ee6da0 RSI: 0000000050009403 RDI: 0000000000000003
RBP: 00007ffdd1ee6da0 R08: 0000000000000000 R09: 00007ffdd1ee67e0
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffdd1ee888e
R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
kworker/u48:1 D 0 2505 2 0x80000000
Workqueue: btrfs-freespace-write btrfs_freespace_write_helper [btrfs]
Call Trace:
? __schedule+0x253/0x860
schedule+0x28/0x80
btrfs_tree_lock+0x130/0x210 [btrfs]
? finish_wait+0x80/0x80
btrfs_search_slot+0x775/0x9f0 [btrfs]
btrfs_mark_extent_written+0xb0/0xb20 [btrfs]
? join_transaction+0x22/0x3e0 [btrfs]
btrfs_finish_ordered_io+0x2e0/0x7e0 [btrfs]
? syscall_return_via_sysret+0x13/0x83
? __switch_to_asm+0x34/0x70
normal_work_helper+0xd3/0x2f0 [btrfs]
process_one_work+0x1a1/0x350
worker_thread+0x30/0x380
? pwq_unbound_release_workfn+0xd0/0xd0
kthread+0x112/0x130
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x35/0x40
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Btrfs resize seems to deadlock
2018-10-20 2:05 Btrfs resize seems to deadlock Andrew Nelson
@ 2018-10-20 20:23 ` Liu Bo
2018-10-20 20:34 ` Filipe Manana
0 siblings, 1 reply; 9+ messages in thread
From: Liu Bo @ 2018-10-20 20:23 UTC (permalink / raw)
To: andrew.s.nelson; +Cc: linux-btrfs
On Fri, Oct 19, 2018 at 7:09 PM Andrew Nelson <andrew.s.nelson@gmail.com> wrote:
>
> I am having an issue with btrfs resize in Fedora 28. I am attempting
> to enlarge my Btrfs partition. Every time I run "btrfs filesystem
> resize max $MOUNT", the command runs for a few minutes and then hangs
> forcing the system to be reset. I am not sure what the state of the
> filesystem really is at this point. Btrfs usage does report the
> correct size for after resizing. Details below:
>
Thanks for the report, the stack is helpful, but this needs a few
deeper debugging, may I ask you to post "btrfs inspect-internal
dump-tree -t 1 /dev/your_btrfs_disk"?
So I'd like to know what's the height of your tree "1" which refers to
root tree in btrfs.
thanks,
liubo
> $ sudo btrfs filesystem usage $MOUNT
> Overall:
> Device size: 90.96TiB
> Device allocated: 72.62TiB
> Device unallocated: 18.33TiB
> Device missing: 0.00B
> Used: 72.62TiB
> Free (estimated): 18.34TiB (min: 9.17TiB)
> Data ratio: 1.00
> Metadata ratio: 2.00
> Global reserve: 512.00MiB (used: 24.11MiB)
>
> Data,single: Size:72.46TiB, Used:72.45TiB
> $MOUNT 72.46TiB
>
> Metadata,DUP: Size:86.00GiB, Used:84.96GiB
> $MOUNT 172.00GiB
>
> System,DUP: Size:40.00MiB, Used:7.53MiB
> $MOUNT 80.00MiB
>
> Unallocated:
> $MOUNT 18.33TiB
>
> $ uname -a
> Linux localhost.localdomain 4.18.14-200.fc28.x86_64 #1 SMP Mon Oct 15
> 13:16:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>
> btrfs-transacti D 0 2501 2 0x80000000
> Call Trace:
> ? __schedule+0x253/0x860
> schedule+0x28/0x80
> btrfs_commit_transaction+0x7aa/0x8b0 [btrfs]
> ? kmem_cache_alloc+0x166/0x1d0
> ? join_transaction+0x22/0x3e0 [btrfs]
> ? finish_wait+0x80/0x80
> transaction_kthread+0x155/0x170 [btrfs]
> ? btrfs_cleanup_transaction+0x550/0x550 [btrfs]
> kthread+0x112/0x130
> ? kthread_create_worker_on_cpu+0x70/0x70
> ret_from_fork+0x35/0x40
> btrfs D 0 2504 2502 0x00000002
> Call Trace:
> ? __schedule+0x253/0x860
> schedule+0x28/0x80
> btrfs_tree_read_lock+0x8e/0x120 [btrfs]
> ? finish_wait+0x80/0x80
> btrfs_read_lock_root_node+0x2f/0x40 [btrfs]
> btrfs_search_slot+0xf6/0x9f0 [btrfs]
> ? evict_refill_and_join+0xd0/0xd0 [btrfs]
> ? inode_insert5+0x119/0x190
> btrfs_lookup_inode+0x3a/0xc0 [btrfs]
> ? kmem_cache_alloc+0x166/0x1d0
> btrfs_iget+0x113/0x690 [btrfs]
> __lookup_free_space_inode+0xd8/0x150 [btrfs]
> lookup_free_space_inode+0x5b/0xb0 [btrfs]
> load_free_space_cache+0x7c/0x170 [btrfs]
> ? cache_block_group+0x72/0x3b0 [btrfs]
> cache_block_group+0x1b3/0x3b0 [btrfs]
> ? finish_wait+0x80/0x80
> find_free_extent+0x799/0x1010 [btrfs]
> btrfs_reserve_extent+0x9b/0x180 [btrfs]
> btrfs_alloc_tree_block+0x1b3/0x4f0 [btrfs]
> __btrfs_cow_block+0x11d/0x500 [btrfs]
> btrfs_cow_block+0xdc/0x180 [btrfs]
> btrfs_search_slot+0x3bd/0x9f0 [btrfs]
> btrfs_lookup_inode+0x3a/0xc0 [btrfs]
> ? kmem_cache_alloc+0x166/0x1d0
> btrfs_update_inode_item+0x46/0x100 [btrfs]
> cache_save_setup+0xe4/0x3a0 [btrfs]
> btrfs_start_dirty_block_groups+0x1be/0x480 [btrfs]
> btrfs_commit_transaction+0xcb/0x8b0 [btrfs]
> ? btrfs_release_path+0x13/0x80 [btrfs]
> ? btrfs_update_device+0x8d/0x1c0 [btrfs]
> btrfs_ioctl_resize.cold.46+0xf4/0xf9 [btrfs]
> btrfs_ioctl+0xa25/0x2cf0 [btrfs]
> ? tty_write+0x1fc/0x330
> ? do_vfs_ioctl+0xa4/0x620
> do_vfs_ioctl+0xa4/0x620
> ksys_ioctl+0x60/0x90
> ? ksys_write+0x4f/0xb0
> __x64_sys_ioctl+0x16/0x20
> do_syscall_64+0x5b/0x160
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7fcdc0d78c57
> Code: Bad RIP value.
> RSP: 002b:00007ffdd1ee6cf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 00007ffdd1ee888a RCX: 00007fcdc0d78c57
> RDX: 00007ffdd1ee6da0 RSI: 0000000050009403 RDI: 0000000000000003
> RBP: 00007ffdd1ee6da0 R08: 0000000000000000 R09: 00007ffdd1ee67e0
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffdd1ee888e
> R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
> kworker/u48:1 D 0 2505 2 0x80000000
> Workqueue: btrfs-freespace-write btrfs_freespace_write_helper [btrfs]
> Call Trace:
> ? __schedule+0x253/0x860
> schedule+0x28/0x80
> btrfs_tree_lock+0x130/0x210 [btrfs]
> ? finish_wait+0x80/0x80
> btrfs_search_slot+0x775/0x9f0 [btrfs]
> btrfs_mark_extent_written+0xb0/0xb20 [btrfs]
> ? join_transaction+0x22/0x3e0 [btrfs]
> btrfs_finish_ordered_io+0x2e0/0x7e0 [btrfs]
> ? syscall_return_via_sysret+0x13/0x83
> ? __switch_to_asm+0x34/0x70
> normal_work_helper+0xd3/0x2f0 [btrfs]
> process_one_work+0x1a1/0x350
> worker_thread+0x30/0x380
> ? pwq_unbound_release_workfn+0xd0/0xd0
> kthread+0x112/0x130
> ? kthread_create_worker_on_cpu+0x70/0x70
> ret_from_fork+0x35/0x40
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Btrfs resize seems to deadlock
2018-10-20 20:23 ` Liu Bo
@ 2018-10-20 20:34 ` Filipe Manana
2018-10-21 5:02 ` Andrew Nelson
2018-10-23 0:18 ` Liu Bo
0 siblings, 2 replies; 9+ messages in thread
From: Filipe Manana @ 2018-10-20 20:34 UTC (permalink / raw)
To: Liu Bo; +Cc: andrew.s.nelson, linux-btrfs
On Sat, Oct 20, 2018 at 9:27 PM Liu Bo <obuil.liubo@gmail.com> wrote:
>
> On Fri, Oct 19, 2018 at 7:09 PM Andrew Nelson <andrew.s.nelson@gmail.com> wrote:
> >
> > I am having an issue with btrfs resize in Fedora 28. I am attempting
> > to enlarge my Btrfs partition. Every time I run "btrfs filesystem
> > resize max $MOUNT", the command runs for a few minutes and then hangs
> > forcing the system to be reset. I am not sure what the state of the
> > filesystem really is at this point. Btrfs usage does report the
> > correct size for after resizing. Details below:
> >
>
> Thanks for the report, the stack is helpful, but this needs a few
> deeper debugging, may I ask you to post "btrfs inspect-internal
> dump-tree -t 1 /dev/your_btrfs_disk"?
I believe it's actually easy to understand from the trace alone and
it's kind of a bad luck scenario.
I made this fix a few hours ago:
https://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git/commit/?h=fix_find_free_extent_deadlock
But haven't done full testing yet and might have missed something.
Bo, can you take a look and let me know what you think?
Thanks.
>
> So I'd like to know what's the height of your tree "1" which refers to
> root tree in btrfs.
>
> thanks,
> liubo
>
> > $ sudo btrfs filesystem usage $MOUNT
> > Overall:
> > Device size: 90.96TiB
> > Device allocated: 72.62TiB
> > Device unallocated: 18.33TiB
> > Device missing: 0.00B
> > Used: 72.62TiB
> > Free (estimated): 18.34TiB (min: 9.17TiB)
> > Data ratio: 1.00
> > Metadata ratio: 2.00
> > Global reserve: 512.00MiB (used: 24.11MiB)
> >
> > Data,single: Size:72.46TiB, Used:72.45TiB
> > $MOUNT 72.46TiB
> >
> > Metadata,DUP: Size:86.00GiB, Used:84.96GiB
> > $MOUNT 172.00GiB
> >
> > System,DUP: Size:40.00MiB, Used:7.53MiB
> > $MOUNT 80.00MiB
> >
> > Unallocated:
> > $MOUNT 18.33TiB
> >
> > $ uname -a
> > Linux localhost.localdomain 4.18.14-200.fc28.x86_64 #1 SMP Mon Oct 15
> > 13:16:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> >
> > btrfs-transacti D 0 2501 2 0x80000000
> > Call Trace:
> > ? __schedule+0x253/0x860
> > schedule+0x28/0x80
> > btrfs_commit_transaction+0x7aa/0x8b0 [btrfs]
> > ? kmem_cache_alloc+0x166/0x1d0
> > ? join_transaction+0x22/0x3e0 [btrfs]
> > ? finish_wait+0x80/0x80
> > transaction_kthread+0x155/0x170 [btrfs]
> > ? btrfs_cleanup_transaction+0x550/0x550 [btrfs]
> > kthread+0x112/0x130
> > ? kthread_create_worker_on_cpu+0x70/0x70
> > ret_from_fork+0x35/0x40
> > btrfs D 0 2504 2502 0x00000002
> > Call Trace:
> > ? __schedule+0x253/0x860
> > schedule+0x28/0x80
> > btrfs_tree_read_lock+0x8e/0x120 [btrfs]
> > ? finish_wait+0x80/0x80
> > btrfs_read_lock_root_node+0x2f/0x40 [btrfs]
> > btrfs_search_slot+0xf6/0x9f0 [btrfs]
> > ? evict_refill_and_join+0xd0/0xd0 [btrfs]
> > ? inode_insert5+0x119/0x190
> > btrfs_lookup_inode+0x3a/0xc0 [btrfs]
> > ? kmem_cache_alloc+0x166/0x1d0
> > btrfs_iget+0x113/0x690 [btrfs]
> > __lookup_free_space_inode+0xd8/0x150 [btrfs]
> > lookup_free_space_inode+0x5b/0xb0 [btrfs]
> > load_free_space_cache+0x7c/0x170 [btrfs]
> > ? cache_block_group+0x72/0x3b0 [btrfs]
> > cache_block_group+0x1b3/0x3b0 [btrfs]
> > ? finish_wait+0x80/0x80
> > find_free_extent+0x799/0x1010 [btrfs]
> > btrfs_reserve_extent+0x9b/0x180 [btrfs]
> > btrfs_alloc_tree_block+0x1b3/0x4f0 [btrfs]
> > __btrfs_cow_block+0x11d/0x500 [btrfs]
> > btrfs_cow_block+0xdc/0x180 [btrfs]
> > btrfs_search_slot+0x3bd/0x9f0 [btrfs]
> > btrfs_lookup_inode+0x3a/0xc0 [btrfs]
> > ? kmem_cache_alloc+0x166/0x1d0
> > btrfs_update_inode_item+0x46/0x100 [btrfs]
> > cache_save_setup+0xe4/0x3a0 [btrfs]
> > btrfs_start_dirty_block_groups+0x1be/0x480 [btrfs]
> > btrfs_commit_transaction+0xcb/0x8b0 [btrfs]
> > ? btrfs_release_path+0x13/0x80 [btrfs]
> > ? btrfs_update_device+0x8d/0x1c0 [btrfs]
> > btrfs_ioctl_resize.cold.46+0xf4/0xf9 [btrfs]
> > btrfs_ioctl+0xa25/0x2cf0 [btrfs]
> > ? tty_write+0x1fc/0x330
> > ? do_vfs_ioctl+0xa4/0x620
> > do_vfs_ioctl+0xa4/0x620
> > ksys_ioctl+0x60/0x90
> > ? ksys_write+0x4f/0xb0
> > __x64_sys_ioctl+0x16/0x20
> > do_syscall_64+0x5b/0x160
> > entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > RIP: 0033:0x7fcdc0d78c57
> > Code: Bad RIP value.
> > RSP: 002b:00007ffdd1ee6cf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> > RAX: ffffffffffffffda RBX: 00007ffdd1ee888a RCX: 00007fcdc0d78c57
> > RDX: 00007ffdd1ee6da0 RSI: 0000000050009403 RDI: 0000000000000003
> > RBP: 00007ffdd1ee6da0 R08: 0000000000000000 R09: 00007ffdd1ee67e0
> > R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffdd1ee888e
> > R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
> > kworker/u48:1 D 0 2505 2 0x80000000
> > Workqueue: btrfs-freespace-write btrfs_freespace_write_helper [btrfs]
> > Call Trace:
> > ? __schedule+0x253/0x860
> > schedule+0x28/0x80
> > btrfs_tree_lock+0x130/0x210 [btrfs]
> > ? finish_wait+0x80/0x80
> > btrfs_search_slot+0x775/0x9f0 [btrfs]
> > btrfs_mark_extent_written+0xb0/0xb20 [btrfs]
> > ? join_transaction+0x22/0x3e0 [btrfs]
> > btrfs_finish_ordered_io+0x2e0/0x7e0 [btrfs]
> > ? syscall_return_via_sysret+0x13/0x83
> > ? __switch_to_asm+0x34/0x70
> > normal_work_helper+0xd3/0x2f0 [btrfs]
> > process_one_work+0x1a1/0x350
> > worker_thread+0x30/0x380
> > ? pwq_unbound_release_workfn+0xd0/0xd0
> > kthread+0x112/0x130
> > ? kthread_create_worker_on_cpu+0x70/0x70
> > ret_from_fork+0x35/0x40
--
Filipe David Manana,
“Whether you think you can, or you think you can't — you're right.”
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Btrfs resize seems to deadlock
2018-10-20 20:34 ` Filipe Manana
@ 2018-10-21 5:02 ` Andrew Nelson
2018-10-21 5:05 ` Andrew Nelson
2018-10-23 0:18 ` Liu Bo
1 sibling, 1 reply; 9+ messages in thread
From: Andrew Nelson @ 2018-10-21 5:02 UTC (permalink / raw)
To: fdmanana; +Cc: obuil.liubo, linux-btrfs
I have ran the "btrfs inspect-internal dump-tree -t 1" command, but
the output is ~55mb. Is there something in particular you are looking
for in this?
On Sat, Oct 20, 2018 at 1:34 PM Filipe Manana <fdmanana@gmail.com> wrote:
>
> On Sat, Oct 20, 2018 at 9:27 PM Liu Bo <obuil.liubo@gmail.com> wrote:
> >
> > On Fri, Oct 19, 2018 at 7:09 PM Andrew Nelson <andrew.s.nelson@gmail.com> wrote:
> > >
> > > I am having an issue with btrfs resize in Fedora 28. I am attempting
> > > to enlarge my Btrfs partition. Every time I run "btrfs filesystem
> > > resize max $MOUNT", the command runs for a few minutes and then hangs
> > > forcing the system to be reset. I am not sure what the state of the
> > > filesystem really is at this point. Btrfs usage does report the
> > > correct size for after resizing. Details below:
> > >
> >
> > Thanks for the report, the stack is helpful, but this needs a few
> > deeper debugging, may I ask you to post "btrfs inspect-internal
> > dump-tree -t 1 /dev/your_btrfs_disk"?
>
> I believe it's actually easy to understand from the trace alone and
> it's kind of a bad luck scenario.
> I made this fix a few hours ago:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git/commit/?h=fix_find_free_extent_deadlock
>
> But haven't done full testing yet and might have missed something.
> Bo, can you take a look and let me know what you think?
>
> Thanks.
>
> >
> > So I'd like to know what's the height of your tree "1" which refers to
> > root tree in btrfs.
> >
> > thanks,
> > liubo
> >
> > > $ sudo btrfs filesystem usage $MOUNT
> > > Overall:
> > > Device size: 90.96TiB
> > > Device allocated: 72.62TiB
> > > Device unallocated: 18.33TiB
> > > Device missing: 0.00B
> > > Used: 72.62TiB
> > > Free (estimated): 18.34TiB (min: 9.17TiB)
> > > Data ratio: 1.00
> > > Metadata ratio: 2.00
> > > Global reserve: 512.00MiB (used: 24.11MiB)
> > >
> > > Data,single: Size:72.46TiB, Used:72.45TiB
> > > $MOUNT 72.46TiB
> > >
> > > Metadata,DUP: Size:86.00GiB, Used:84.96GiB
> > > $MOUNT 172.00GiB
> > >
> > > System,DUP: Size:40.00MiB, Used:7.53MiB
> > > $MOUNT 80.00MiB
> > >
> > > Unallocated:
> > > $MOUNT 18.33TiB
> > >
> > > $ uname -a
> > > Linux localhost.localdomain 4.18.14-200.fc28.x86_64 #1 SMP Mon Oct 15
> > > 13:16:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> > >
> > > btrfs-transacti D 0 2501 2 0x80000000
> > > Call Trace:
> > > ? __schedule+0x253/0x860
> > > schedule+0x28/0x80
> > > btrfs_commit_transaction+0x7aa/0x8b0 [btrfs]
> > > ? kmem_cache_alloc+0x166/0x1d0
> > > ? join_transaction+0x22/0x3e0 [btrfs]
> > > ? finish_wait+0x80/0x80
> > > transaction_kthread+0x155/0x170 [btrfs]
> > > ? btrfs_cleanup_transaction+0x550/0x550 [btrfs]
> > > kthread+0x112/0x130
> > > ? kthread_create_worker_on_cpu+0x70/0x70
> > > ret_from_fork+0x35/0x40
> > > btrfs D 0 2504 2502 0x00000002
> > > Call Trace:
> > > ? __schedule+0x253/0x860
> > > schedule+0x28/0x80
> > > btrfs_tree_read_lock+0x8e/0x120 [btrfs]
> > > ? finish_wait+0x80/0x80
> > > btrfs_read_lock_root_node+0x2f/0x40 [btrfs]
> > > btrfs_search_slot+0xf6/0x9f0 [btrfs]
> > > ? evict_refill_and_join+0xd0/0xd0 [btrfs]
> > > ? inode_insert5+0x119/0x190
> > > btrfs_lookup_inode+0x3a/0xc0 [btrfs]
> > > ? kmem_cache_alloc+0x166/0x1d0
> > > btrfs_iget+0x113/0x690 [btrfs]
> > > __lookup_free_space_inode+0xd8/0x150 [btrfs]
> > > lookup_free_space_inode+0x5b/0xb0 [btrfs]
> > > load_free_space_cache+0x7c/0x170 [btrfs]
> > > ? cache_block_group+0x72/0x3b0 [btrfs]
> > > cache_block_group+0x1b3/0x3b0 [btrfs]
> > > ? finish_wait+0x80/0x80
> > > find_free_extent+0x799/0x1010 [btrfs]
> > > btrfs_reserve_extent+0x9b/0x180 [btrfs]
> > > btrfs_alloc_tree_block+0x1b3/0x4f0 [btrfs]
> > > __btrfs_cow_block+0x11d/0x500 [btrfs]
> > > btrfs_cow_block+0xdc/0x180 [btrfs]
> > > btrfs_search_slot+0x3bd/0x9f0 [btrfs]
> > > btrfs_lookup_inode+0x3a/0xc0 [btrfs]
> > > ? kmem_cache_alloc+0x166/0x1d0
> > > btrfs_update_inode_item+0x46/0x100 [btrfs]
> > > cache_save_setup+0xe4/0x3a0 [btrfs]
> > > btrfs_start_dirty_block_groups+0x1be/0x480 [btrfs]
> > > btrfs_commit_transaction+0xcb/0x8b0 [btrfs]
> > > ? btrfs_release_path+0x13/0x80 [btrfs]
> > > ? btrfs_update_device+0x8d/0x1c0 [btrfs]
> > > btrfs_ioctl_resize.cold.46+0xf4/0xf9 [btrfs]
> > > btrfs_ioctl+0xa25/0x2cf0 [btrfs]
> > > ? tty_write+0x1fc/0x330
> > > ? do_vfs_ioctl+0xa4/0x620
> > > do_vfs_ioctl+0xa4/0x620
> > > ksys_ioctl+0x60/0x90
> > > ? ksys_write+0x4f/0xb0
> > > __x64_sys_ioctl+0x16/0x20
> > > do_syscall_64+0x5b/0x160
> > > entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > RIP: 0033:0x7fcdc0d78c57
> > > Code: Bad RIP value.
> > > RSP: 002b:00007ffdd1ee6cf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> > > RAX: ffffffffffffffda RBX: 00007ffdd1ee888a RCX: 00007fcdc0d78c57
> > > RDX: 00007ffdd1ee6da0 RSI: 0000000050009403 RDI: 0000000000000003
> > > RBP: 00007ffdd1ee6da0 R08: 0000000000000000 R09: 00007ffdd1ee67e0
> > > R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffdd1ee888e
> > > R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
> > > kworker/u48:1 D 0 2505 2 0x80000000
> > > Workqueue: btrfs-freespace-write btrfs_freespace_write_helper [btrfs]
> > > Call Trace:
> > > ? __schedule+0x253/0x860
> > > schedule+0x28/0x80
> > > btrfs_tree_lock+0x130/0x210 [btrfs]
> > > ? finish_wait+0x80/0x80
> > > btrfs_search_slot+0x775/0x9f0 [btrfs]
> > > btrfs_mark_extent_written+0xb0/0xb20 [btrfs]
> > > ? join_transaction+0x22/0x3e0 [btrfs]
> > > btrfs_finish_ordered_io+0x2e0/0x7e0 [btrfs]
> > > ? syscall_return_via_sysret+0x13/0x83
> > > ? __switch_to_asm+0x34/0x70
> > > normal_work_helper+0xd3/0x2f0 [btrfs]
> > > process_one_work+0x1a1/0x350
> > > worker_thread+0x30/0x380
> > > ? pwq_unbound_release_workfn+0xd0/0xd0
> > > kthread+0x112/0x130
> > > ? kthread_create_worker_on_cpu+0x70/0x70
> > > ret_from_fork+0x35/0x40
>
>
>
> --
> Filipe David Manana,
>
> “Whether you think you can, or you think you can't — you're right.”
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Btrfs resize seems to deadlock
2018-10-21 5:02 ` Andrew Nelson
@ 2018-10-21 5:05 ` Andrew Nelson
2018-10-21 8:56 ` Filipe Manana
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Nelson @ 2018-10-21 5:05 UTC (permalink / raw)
To: fdmanana; +Cc: obuil.liubo, linux-btrfs
Also, is the drive in a safe state to use? Is there anything I should
run on the drive to check consistency?
On Sat, Oct 20, 2018 at 10:02 PM Andrew Nelson
<andrew.s.nelson@gmail.com> wrote:
>
> I have ran the "btrfs inspect-internal dump-tree -t 1" command, but
> the output is ~55mb. Is there something in particular you are looking
> for in this?
> On Sat, Oct 20, 2018 at 1:34 PM Filipe Manana <fdmanana@gmail.com> wrote:
> >
> > On Sat, Oct 20, 2018 at 9:27 PM Liu Bo <obuil.liubo@gmail.com> wrote:
> > >
> > > On Fri, Oct 19, 2018 at 7:09 PM Andrew Nelson <andrew.s.nelson@gmail.com> wrote:
> > > >
> > > > I am having an issue with btrfs resize in Fedora 28. I am attempting
> > > > to enlarge my Btrfs partition. Every time I run "btrfs filesystem
> > > > resize max $MOUNT", the command runs for a few minutes and then hangs
> > > > forcing the system to be reset. I am not sure what the state of the
> > > > filesystem really is at this point. Btrfs usage does report the
> > > > correct size for after resizing. Details below:
> > > >
> > >
> > > Thanks for the report, the stack is helpful, but this needs a few
> > > deeper debugging, may I ask you to post "btrfs inspect-internal
> > > dump-tree -t 1 /dev/your_btrfs_disk"?
> >
> > I believe it's actually easy to understand from the trace alone and
> > it's kind of a bad luck scenario.
> > I made this fix a few hours ago:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git/commit/?h=fix_find_free_extent_deadlock
> >
> > But haven't done full testing yet and might have missed something.
> > Bo, can you take a look and let me know what you think?
> >
> > Thanks.
> >
> > >
> > > So I'd like to know what's the height of your tree "1" which refers to
> > > root tree in btrfs.
> > >
> > > thanks,
> > > liubo
> > >
> > > > $ sudo btrfs filesystem usage $MOUNT
> > > > Overall:
> > > > Device size: 90.96TiB
> > > > Device allocated: 72.62TiB
> > > > Device unallocated: 18.33TiB
> > > > Device missing: 0.00B
> > > > Used: 72.62TiB
> > > > Free (estimated): 18.34TiB (min: 9.17TiB)
> > > > Data ratio: 1.00
> > > > Metadata ratio: 2.00
> > > > Global reserve: 512.00MiB (used: 24.11MiB)
> > > >
> > > > Data,single: Size:72.46TiB, Used:72.45TiB
> > > > $MOUNT 72.46TiB
> > > >
> > > > Metadata,DUP: Size:86.00GiB, Used:84.96GiB
> > > > $MOUNT 172.00GiB
> > > >
> > > > System,DUP: Size:40.00MiB, Used:7.53MiB
> > > > $MOUNT 80.00MiB
> > > >
> > > > Unallocated:
> > > > $MOUNT 18.33TiB
> > > >
> > > > $ uname -a
> > > > Linux localhost.localdomain 4.18.14-200.fc28.x86_64 #1 SMP Mon Oct 15
> > > > 13:16:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> > > >
> > > > btrfs-transacti D 0 2501 2 0x80000000
> > > > Call Trace:
> > > > ? __schedule+0x253/0x860
> > > > schedule+0x28/0x80
> > > > btrfs_commit_transaction+0x7aa/0x8b0 [btrfs]
> > > > ? kmem_cache_alloc+0x166/0x1d0
> > > > ? join_transaction+0x22/0x3e0 [btrfs]
> > > > ? finish_wait+0x80/0x80
> > > > transaction_kthread+0x155/0x170 [btrfs]
> > > > ? btrfs_cleanup_transaction+0x550/0x550 [btrfs]
> > > > kthread+0x112/0x130
> > > > ? kthread_create_worker_on_cpu+0x70/0x70
> > > > ret_from_fork+0x35/0x40
> > > > btrfs D 0 2504 2502 0x00000002
> > > > Call Trace:
> > > > ? __schedule+0x253/0x860
> > > > schedule+0x28/0x80
> > > > btrfs_tree_read_lock+0x8e/0x120 [btrfs]
> > > > ? finish_wait+0x80/0x80
> > > > btrfs_read_lock_root_node+0x2f/0x40 [btrfs]
> > > > btrfs_search_slot+0xf6/0x9f0 [btrfs]
> > > > ? evict_refill_and_join+0xd0/0xd0 [btrfs]
> > > > ? inode_insert5+0x119/0x190
> > > > btrfs_lookup_inode+0x3a/0xc0 [btrfs]
> > > > ? kmem_cache_alloc+0x166/0x1d0
> > > > btrfs_iget+0x113/0x690 [btrfs]
> > > > __lookup_free_space_inode+0xd8/0x150 [btrfs]
> > > > lookup_free_space_inode+0x5b/0xb0 [btrfs]
> > > > load_free_space_cache+0x7c/0x170 [btrfs]
> > > > ? cache_block_group+0x72/0x3b0 [btrfs]
> > > > cache_block_group+0x1b3/0x3b0 [btrfs]
> > > > ? finish_wait+0x80/0x80
> > > > find_free_extent+0x799/0x1010 [btrfs]
> > > > btrfs_reserve_extent+0x9b/0x180 [btrfs]
> > > > btrfs_alloc_tree_block+0x1b3/0x4f0 [btrfs]
> > > > __btrfs_cow_block+0x11d/0x500 [btrfs]
> > > > btrfs_cow_block+0xdc/0x180 [btrfs]
> > > > btrfs_search_slot+0x3bd/0x9f0 [btrfs]
> > > > btrfs_lookup_inode+0x3a/0xc0 [btrfs]
> > > > ? kmem_cache_alloc+0x166/0x1d0
> > > > btrfs_update_inode_item+0x46/0x100 [btrfs]
> > > > cache_save_setup+0xe4/0x3a0 [btrfs]
> > > > btrfs_start_dirty_block_groups+0x1be/0x480 [btrfs]
> > > > btrfs_commit_transaction+0xcb/0x8b0 [btrfs]
> > > > ? btrfs_release_path+0x13/0x80 [btrfs]
> > > > ? btrfs_update_device+0x8d/0x1c0 [btrfs]
> > > > btrfs_ioctl_resize.cold.46+0xf4/0xf9 [btrfs]
> > > > btrfs_ioctl+0xa25/0x2cf0 [btrfs]
> > > > ? tty_write+0x1fc/0x330
> > > > ? do_vfs_ioctl+0xa4/0x620
> > > > do_vfs_ioctl+0xa4/0x620
> > > > ksys_ioctl+0x60/0x90
> > > > ? ksys_write+0x4f/0xb0
> > > > __x64_sys_ioctl+0x16/0x20
> > > > do_syscall_64+0x5b/0x160
> > > > entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > > RIP: 0033:0x7fcdc0d78c57
> > > > Code: Bad RIP value.
> > > > RSP: 002b:00007ffdd1ee6cf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> > > > RAX: ffffffffffffffda RBX: 00007ffdd1ee888a RCX: 00007fcdc0d78c57
> > > > RDX: 00007ffdd1ee6da0 RSI: 0000000050009403 RDI: 0000000000000003
> > > > RBP: 00007ffdd1ee6da0 R08: 0000000000000000 R09: 00007ffdd1ee67e0
> > > > R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffdd1ee888e
> > > > R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
> > > > kworker/u48:1 D 0 2505 2 0x80000000
> > > > Workqueue: btrfs-freespace-write btrfs_freespace_write_helper [btrfs]
> > > > Call Trace:
> > > > ? __schedule+0x253/0x860
> > > > schedule+0x28/0x80
> > > > btrfs_tree_lock+0x130/0x210 [btrfs]
> > > > ? finish_wait+0x80/0x80
> > > > btrfs_search_slot+0x775/0x9f0 [btrfs]
> > > > btrfs_mark_extent_written+0xb0/0xb20 [btrfs]
> > > > ? join_transaction+0x22/0x3e0 [btrfs]
> > > > btrfs_finish_ordered_io+0x2e0/0x7e0 [btrfs]
> > > > ? syscall_return_via_sysret+0x13/0x83
> > > > ? __switch_to_asm+0x34/0x70
> > > > normal_work_helper+0xd3/0x2f0 [btrfs]
> > > > process_one_work+0x1a1/0x350
> > > > worker_thread+0x30/0x380
> > > > ? pwq_unbound_release_workfn+0xd0/0xd0
> > > > kthread+0x112/0x130
> > > > ? kthread_create_worker_on_cpu+0x70/0x70
> > > > ret_from_fork+0x35/0x40
> >
> >
> >
> > --
> > Filipe David Manana,
> >
> > “Whether you think you can, or you think you can't — you're right.”
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Btrfs resize seems to deadlock
2018-10-21 5:05 ` Andrew Nelson
@ 2018-10-21 8:56 ` Filipe Manana
2018-10-22 9:06 ` Andrew Nelson
0 siblings, 1 reply; 9+ messages in thread
From: Filipe Manana @ 2018-10-21 8:56 UTC (permalink / raw)
To: andrew.s.nelson; +Cc: Liu Bo, linux-btrfs
On Sun, Oct 21, 2018 at 6:05 AM Andrew Nelson <andrew.s.nelson@gmail.com> wrote:
>
> Also, is the drive in a safe state to use? Is there anything I should
> run on the drive to check consistency?
It should be in a safe state. You can verify it running "btrfs check
/dev/<your device>" (it's a readonly operation).
If you are able to patch and build a kernel, you can also try the
patch. I left it running tests overnight and haven't got any
regressions.
Thanks.
> On Sat, Oct 20, 2018 at 10:02 PM Andrew Nelson
> <andrew.s.nelson@gmail.com> wrote:
> >
> > I have ran the "btrfs inspect-internal dump-tree -t 1" command, but
> > the output is ~55mb. Is there something in particular you are looking
> > for in this?
> > On Sat, Oct 20, 2018 at 1:34 PM Filipe Manana <fdmanana@gmail.com> wrote:
> > >
> > > On Sat, Oct 20, 2018 at 9:27 PM Liu Bo <obuil.liubo@gmail.com> wrote:
> > > >
> > > > On Fri, Oct 19, 2018 at 7:09 PM Andrew Nelson <andrew.s.nelson@gmail.com> wrote:
> > > > >
> > > > > I am having an issue with btrfs resize in Fedora 28. I am attempting
> > > > > to enlarge my Btrfs partition. Every time I run "btrfs filesystem
> > > > > resize max $MOUNT", the command runs for a few minutes and then hangs
> > > > > forcing the system to be reset. I am not sure what the state of the
> > > > > filesystem really is at this point. Btrfs usage does report the
> > > > > correct size for after resizing. Details below:
> > > > >
> > > >
> > > > Thanks for the report, the stack is helpful, but this needs a few
> > > > deeper debugging, may I ask you to post "btrfs inspect-internal
> > > > dump-tree -t 1 /dev/your_btrfs_disk"?
> > >
> > > I believe it's actually easy to understand from the trace alone and
> > > it's kind of a bad luck scenario.
> > > I made this fix a few hours ago:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git/commit/?h=fix_find_free_extent_deadlock
> > >
> > > But haven't done full testing yet and might have missed something.
> > > Bo, can you take a look and let me know what you think?
> > >
> > > Thanks.
> > >
> > > >
> > > > So I'd like to know what's the height of your tree "1" which refers to
> > > > root tree in btrfs.
> > > >
> > > > thanks,
> > > > liubo
> > > >
> > > > > $ sudo btrfs filesystem usage $MOUNT
> > > > > Overall:
> > > > > Device size: 90.96TiB
> > > > > Device allocated: 72.62TiB
> > > > > Device unallocated: 18.33TiB
> > > > > Device missing: 0.00B
> > > > > Used: 72.62TiB
> > > > > Free (estimated): 18.34TiB (min: 9.17TiB)
> > > > > Data ratio: 1.00
> > > > > Metadata ratio: 2.00
> > > > > Global reserve: 512.00MiB (used: 24.11MiB)
> > > > >
> > > > > Data,single: Size:72.46TiB, Used:72.45TiB
> > > > > $MOUNT 72.46TiB
> > > > >
> > > > > Metadata,DUP: Size:86.00GiB, Used:84.96GiB
> > > > > $MOUNT 172.00GiB
> > > > >
> > > > > System,DUP: Size:40.00MiB, Used:7.53MiB
> > > > > $MOUNT 80.00MiB
> > > > >
> > > > > Unallocated:
> > > > > $MOUNT 18.33TiB
> > > > >
> > > > > $ uname -a
> > > > > Linux localhost.localdomain 4.18.14-200.fc28.x86_64 #1 SMP Mon Oct 15
> > > > > 13:16:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> > > > >
> > > > > btrfs-transacti D 0 2501 2 0x80000000
> > > > > Call Trace:
> > > > > ? __schedule+0x253/0x860
> > > > > schedule+0x28/0x80
> > > > > btrfs_commit_transaction+0x7aa/0x8b0 [btrfs]
> > > > > ? kmem_cache_alloc+0x166/0x1d0
> > > > > ? join_transaction+0x22/0x3e0 [btrfs]
> > > > > ? finish_wait+0x80/0x80
> > > > > transaction_kthread+0x155/0x170 [btrfs]
> > > > > ? btrfs_cleanup_transaction+0x550/0x550 [btrfs]
> > > > > kthread+0x112/0x130
> > > > > ? kthread_create_worker_on_cpu+0x70/0x70
> > > > > ret_from_fork+0x35/0x40
> > > > > btrfs D 0 2504 2502 0x00000002
> > > > > Call Trace:
> > > > > ? __schedule+0x253/0x860
> > > > > schedule+0x28/0x80
> > > > > btrfs_tree_read_lock+0x8e/0x120 [btrfs]
> > > > > ? finish_wait+0x80/0x80
> > > > > btrfs_read_lock_root_node+0x2f/0x40 [btrfs]
> > > > > btrfs_search_slot+0xf6/0x9f0 [btrfs]
> > > > > ? evict_refill_and_join+0xd0/0xd0 [btrfs]
> > > > > ? inode_insert5+0x119/0x190
> > > > > btrfs_lookup_inode+0x3a/0xc0 [btrfs]
> > > > > ? kmem_cache_alloc+0x166/0x1d0
> > > > > btrfs_iget+0x113/0x690 [btrfs]
> > > > > __lookup_free_space_inode+0xd8/0x150 [btrfs]
> > > > > lookup_free_space_inode+0x5b/0xb0 [btrfs]
> > > > > load_free_space_cache+0x7c/0x170 [btrfs]
> > > > > ? cache_block_group+0x72/0x3b0 [btrfs]
> > > > > cache_block_group+0x1b3/0x3b0 [btrfs]
> > > > > ? finish_wait+0x80/0x80
> > > > > find_free_extent+0x799/0x1010 [btrfs]
> > > > > btrfs_reserve_extent+0x9b/0x180 [btrfs]
> > > > > btrfs_alloc_tree_block+0x1b3/0x4f0 [btrfs]
> > > > > __btrfs_cow_block+0x11d/0x500 [btrfs]
> > > > > btrfs_cow_block+0xdc/0x180 [btrfs]
> > > > > btrfs_search_slot+0x3bd/0x9f0 [btrfs]
> > > > > btrfs_lookup_inode+0x3a/0xc0 [btrfs]
> > > > > ? kmem_cache_alloc+0x166/0x1d0
> > > > > btrfs_update_inode_item+0x46/0x100 [btrfs]
> > > > > cache_save_setup+0xe4/0x3a0 [btrfs]
> > > > > btrfs_start_dirty_block_groups+0x1be/0x480 [btrfs]
> > > > > btrfs_commit_transaction+0xcb/0x8b0 [btrfs]
> > > > > ? btrfs_release_path+0x13/0x80 [btrfs]
> > > > > ? btrfs_update_device+0x8d/0x1c0 [btrfs]
> > > > > btrfs_ioctl_resize.cold.46+0xf4/0xf9 [btrfs]
> > > > > btrfs_ioctl+0xa25/0x2cf0 [btrfs]
> > > > > ? tty_write+0x1fc/0x330
> > > > > ? do_vfs_ioctl+0xa4/0x620
> > > > > do_vfs_ioctl+0xa4/0x620
> > > > > ksys_ioctl+0x60/0x90
> > > > > ? ksys_write+0x4f/0xb0
> > > > > __x64_sys_ioctl+0x16/0x20
> > > > > do_syscall_64+0x5b/0x160
> > > > > entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > > > RIP: 0033:0x7fcdc0d78c57
> > > > > Code: Bad RIP value.
> > > > > RSP: 002b:00007ffdd1ee6cf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> > > > > RAX: ffffffffffffffda RBX: 00007ffdd1ee888a RCX: 00007fcdc0d78c57
> > > > > RDX: 00007ffdd1ee6da0 RSI: 0000000050009403 RDI: 0000000000000003
> > > > > RBP: 00007ffdd1ee6da0 R08: 0000000000000000 R09: 00007ffdd1ee67e0
> > > > > R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffdd1ee888e
> > > > > R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
> > > > > kworker/u48:1 D 0 2505 2 0x80000000
> > > > > Workqueue: btrfs-freespace-write btrfs_freespace_write_helper [btrfs]
> > > > > Call Trace:
> > > > > ? __schedule+0x253/0x860
> > > > > schedule+0x28/0x80
> > > > > btrfs_tree_lock+0x130/0x210 [btrfs]
> > > > > ? finish_wait+0x80/0x80
> > > > > btrfs_search_slot+0x775/0x9f0 [btrfs]
> > > > > btrfs_mark_extent_written+0xb0/0xb20 [btrfs]
> > > > > ? join_transaction+0x22/0x3e0 [btrfs]
> > > > > btrfs_finish_ordered_io+0x2e0/0x7e0 [btrfs]
> > > > > ? syscall_return_via_sysret+0x13/0x83
> > > > > ? __switch_to_asm+0x34/0x70
> > > > > normal_work_helper+0xd3/0x2f0 [btrfs]
> > > > > process_one_work+0x1a1/0x350
> > > > > worker_thread+0x30/0x380
> > > > > ? pwq_unbound_release_workfn+0xd0/0xd0
> > > > > kthread+0x112/0x130
> > > > > ? kthread_create_worker_on_cpu+0x70/0x70
> > > > > ret_from_fork+0x35/0x40
> > >
> > >
> > >
> > > --
> > > Filipe David Manana,
> > >
> > > “Whether you think you can, or you think you can't — you're right.”
--
Filipe David Manana,
“Whether you think you can, or you think you can't — you're right.”
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Btrfs resize seems to deadlock
2018-10-21 8:56 ` Filipe Manana
@ 2018-10-22 9:06 ` Andrew Nelson
2018-10-22 9:12 ` Filipe Manana
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Nelson @ 2018-10-22 9:06 UTC (permalink / raw)
To: fdmanana; +Cc: obuil.liubo, linux-btrfs
OK, an update: After unmouting and running btrfs check, the drive
reverted to reporting the old size. Not sure if this was due to
unmounting / mounting or doing btrfs check. Btrfs check should have
been running in readonly mode. Since it looked like something was
wrong with the resize process, I patched my kernel with the posted
patch. This time the resize operation finished successfully.
On Sun, Oct 21, 2018 at 1:56 AM Filipe Manana <fdmanana@gmail.com> wrote:
>
> On Sun, Oct 21, 2018 at 6:05 AM Andrew Nelson <andrew.s.nelson@gmail.com> wrote:
> >
> > Also, is the drive in a safe state to use? Is there anything I should
> > run on the drive to check consistency?
>
> It should be in a safe state. You can verify it running "btrfs check
> /dev/<your device>" (it's a readonly operation).
>
> If you are able to patch and build a kernel, you can also try the
> patch. I left it running tests overnight and haven't got any
> regressions.
>
> Thanks.
>
> > On Sat, Oct 20, 2018 at 10:02 PM Andrew Nelson
> > <andrew.s.nelson@gmail.com> wrote:
> > >
> > > I have ran the "btrfs inspect-internal dump-tree -t 1" command, but
> > > the output is ~55mb. Is there something in particular you are looking
> > > for in this?
> > > On Sat, Oct 20, 2018 at 1:34 PM Filipe Manana <fdmanana@gmail.com> wrote:
> > > >
> > > > On Sat, Oct 20, 2018 at 9:27 PM Liu Bo <obuil.liubo@gmail.com> wrote:
> > > > >
> > > > > On Fri, Oct 19, 2018 at 7:09 PM Andrew Nelson <andrew.s.nelson@gmail.com> wrote:
> > > > > >
> > > > > > I am having an issue with btrfs resize in Fedora 28. I am attempting
> > > > > > to enlarge my Btrfs partition. Every time I run "btrfs filesystem
> > > > > > resize max $MOUNT", the command runs for a few minutes and then hangs
> > > > > > forcing the system to be reset. I am not sure what the state of the
> > > > > > filesystem really is at this point. Btrfs usage does report the
> > > > > > correct size for after resizing. Details below:
> > > > > >
> > > > >
> > > > > Thanks for the report, the stack is helpful, but this needs a few
> > > > > deeper debugging, may I ask you to post "btrfs inspect-internal
> > > > > dump-tree -t 1 /dev/your_btrfs_disk"?
> > > >
> > > > I believe it's actually easy to understand from the trace alone and
> > > > it's kind of a bad luck scenario.
> > > > I made this fix a few hours ago:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git/commit/?h=fix_find_free_extent_deadlock
> > > >
> > > > But haven't done full testing yet and might have missed something.
> > > > Bo, can you take a look and let me know what you think?
> > > >
> > > > Thanks.
> > > >
> > > > >
> > > > > So I'd like to know what's the height of your tree "1" which refers to
> > > > > root tree in btrfs.
> > > > >
> > > > > thanks,
> > > > > liubo
> > > > >
> > > > > > $ sudo btrfs filesystem usage $MOUNT
> > > > > > Overall:
> > > > > > Device size: 90.96TiB
> > > > > > Device allocated: 72.62TiB
> > > > > > Device unallocated: 18.33TiB
> > > > > > Device missing: 0.00B
> > > > > > Used: 72.62TiB
> > > > > > Free (estimated): 18.34TiB (min: 9.17TiB)
> > > > > > Data ratio: 1.00
> > > > > > Metadata ratio: 2.00
> > > > > > Global reserve: 512.00MiB (used: 24.11MiB)
> > > > > >
> > > > > > Data,single: Size:72.46TiB, Used:72.45TiB
> > > > > > $MOUNT 72.46TiB
> > > > > >
> > > > > > Metadata,DUP: Size:86.00GiB, Used:84.96GiB
> > > > > > $MOUNT 172.00GiB
> > > > > >
> > > > > > System,DUP: Size:40.00MiB, Used:7.53MiB
> > > > > > $MOUNT 80.00MiB
> > > > > >
> > > > > > Unallocated:
> > > > > > $MOUNT 18.33TiB
> > > > > >
> > > > > > $ uname -a
> > > > > > Linux localhost.localdomain 4.18.14-200.fc28.x86_64 #1 SMP Mon Oct 15
> > > > > > 13:16:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> > > > > >
> > > > > > btrfs-transacti D 0 2501 2 0x80000000
> > > > > > Call Trace:
> > > > > > ? __schedule+0x253/0x860
> > > > > > schedule+0x28/0x80
> > > > > > btrfs_commit_transaction+0x7aa/0x8b0 [btrfs]
> > > > > > ? kmem_cache_alloc+0x166/0x1d0
> > > > > > ? join_transaction+0x22/0x3e0 [btrfs]
> > > > > > ? finish_wait+0x80/0x80
> > > > > > transaction_kthread+0x155/0x170 [btrfs]
> > > > > > ? btrfs_cleanup_transaction+0x550/0x550 [btrfs]
> > > > > > kthread+0x112/0x130
> > > > > > ? kthread_create_worker_on_cpu+0x70/0x70
> > > > > > ret_from_fork+0x35/0x40
> > > > > > btrfs D 0 2504 2502 0x00000002
> > > > > > Call Trace:
> > > > > > ? __schedule+0x253/0x860
> > > > > > schedule+0x28/0x80
> > > > > > btrfs_tree_read_lock+0x8e/0x120 [btrfs]
> > > > > > ? finish_wait+0x80/0x80
> > > > > > btrfs_read_lock_root_node+0x2f/0x40 [btrfs]
> > > > > > btrfs_search_slot+0xf6/0x9f0 [btrfs]
> > > > > > ? evict_refill_and_join+0xd0/0xd0 [btrfs]
> > > > > > ? inode_insert5+0x119/0x190
> > > > > > btrfs_lookup_inode+0x3a/0xc0 [btrfs]
> > > > > > ? kmem_cache_alloc+0x166/0x1d0
> > > > > > btrfs_iget+0x113/0x690 [btrfs]
> > > > > > __lookup_free_space_inode+0xd8/0x150 [btrfs]
> > > > > > lookup_free_space_inode+0x5b/0xb0 [btrfs]
> > > > > > load_free_space_cache+0x7c/0x170 [btrfs]
> > > > > > ? cache_block_group+0x72/0x3b0 [btrfs]
> > > > > > cache_block_group+0x1b3/0x3b0 [btrfs]
> > > > > > ? finish_wait+0x80/0x80
> > > > > > find_free_extent+0x799/0x1010 [btrfs]
> > > > > > btrfs_reserve_extent+0x9b/0x180 [btrfs]
> > > > > > btrfs_alloc_tree_block+0x1b3/0x4f0 [btrfs]
> > > > > > __btrfs_cow_block+0x11d/0x500 [btrfs]
> > > > > > btrfs_cow_block+0xdc/0x180 [btrfs]
> > > > > > btrfs_search_slot+0x3bd/0x9f0 [btrfs]
> > > > > > btrfs_lookup_inode+0x3a/0xc0 [btrfs]
> > > > > > ? kmem_cache_alloc+0x166/0x1d0
> > > > > > btrfs_update_inode_item+0x46/0x100 [btrfs]
> > > > > > cache_save_setup+0xe4/0x3a0 [btrfs]
> > > > > > btrfs_start_dirty_block_groups+0x1be/0x480 [btrfs]
> > > > > > btrfs_commit_transaction+0xcb/0x8b0 [btrfs]
> > > > > > ? btrfs_release_path+0x13/0x80 [btrfs]
> > > > > > ? btrfs_update_device+0x8d/0x1c0 [btrfs]
> > > > > > btrfs_ioctl_resize.cold.46+0xf4/0xf9 [btrfs]
> > > > > > btrfs_ioctl+0xa25/0x2cf0 [btrfs]
> > > > > > ? tty_write+0x1fc/0x330
> > > > > > ? do_vfs_ioctl+0xa4/0x620
> > > > > > do_vfs_ioctl+0xa4/0x620
> > > > > > ksys_ioctl+0x60/0x90
> > > > > > ? ksys_write+0x4f/0xb0
> > > > > > __x64_sys_ioctl+0x16/0x20
> > > > > > do_syscall_64+0x5b/0x160
> > > > > > entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > > > > RIP: 0033:0x7fcdc0d78c57
> > > > > > Code: Bad RIP value.
> > > > > > RSP: 002b:00007ffdd1ee6cf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> > > > > > RAX: ffffffffffffffda RBX: 00007ffdd1ee888a RCX: 00007fcdc0d78c57
> > > > > > RDX: 00007ffdd1ee6da0 RSI: 0000000050009403 RDI: 0000000000000003
> > > > > > RBP: 00007ffdd1ee6da0 R08: 0000000000000000 R09: 00007ffdd1ee67e0
> > > > > > R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffdd1ee888e
> > > > > > R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
> > > > > > kworker/u48:1 D 0 2505 2 0x80000000
> > > > > > Workqueue: btrfs-freespace-write btrfs_freespace_write_helper [btrfs]
> > > > > > Call Trace:
> > > > > > ? __schedule+0x253/0x860
> > > > > > schedule+0x28/0x80
> > > > > > btrfs_tree_lock+0x130/0x210 [btrfs]
> > > > > > ? finish_wait+0x80/0x80
> > > > > > btrfs_search_slot+0x775/0x9f0 [btrfs]
> > > > > > btrfs_mark_extent_written+0xb0/0xb20 [btrfs]
> > > > > > ? join_transaction+0x22/0x3e0 [btrfs]
> > > > > > btrfs_finish_ordered_io+0x2e0/0x7e0 [btrfs]
> > > > > > ? syscall_return_via_sysret+0x13/0x83
> > > > > > ? __switch_to_asm+0x34/0x70
> > > > > > normal_work_helper+0xd3/0x2f0 [btrfs]
> > > > > > process_one_work+0x1a1/0x350
> > > > > > worker_thread+0x30/0x380
> > > > > > ? pwq_unbound_release_workfn+0xd0/0xd0
> > > > > > kthread+0x112/0x130
> > > > > > ? kthread_create_worker_on_cpu+0x70/0x70
> > > > > > ret_from_fork+0x35/0x40
> > > >
> > > >
> > > >
> > > > --
> > > > Filipe David Manana,
> > > >
> > > > “Whether you think you can, or you think you can't — you're right.”
>
>
>
> --
> Filipe David Manana,
>
> “Whether you think you can, or you think you can't — you're right.”
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Btrfs resize seems to deadlock
2018-10-22 9:06 ` Andrew Nelson
@ 2018-10-22 9:12 ` Filipe Manana
0 siblings, 0 replies; 9+ messages in thread
From: Filipe Manana @ 2018-10-22 9:12 UTC (permalink / raw)
To: andrew.s.nelson; +Cc: Liu Bo, linux-btrfs
On Mon, Oct 22, 2018 at 10:06 AM Andrew Nelson
<andrew.s.nelson@gmail.com> wrote:
>
> OK, an update: After unmouting and running btrfs check, the drive
> reverted to reporting the old size. Not sure if this was due to
> unmounting / mounting or doing btrfs check. Btrfs check should have
> been running in readonly mode.
It reverted to the old size because the transaction used for the
resize operation never got committed due to the deadlock, not because
of 'btrfs check'.
> Since it looked like something was
> wrong with the resize process, I patched my kernel with the posted
> patch. This time the resize operation finished successfully.
Great, thanks for testing!
> On Sun, Oct 21, 2018 at 1:56 AM Filipe Manana <fdmanana@gmail.com> wrote:
> >
> > On Sun, Oct 21, 2018 at 6:05 AM Andrew Nelson <andrew.s.nelson@gmail.com> wrote:
> > >
> > > Also, is the drive in a safe state to use? Is there anything I should
> > > run on the drive to check consistency?
> >
> > It should be in a safe state. You can verify it running "btrfs check
> > /dev/<your device>" (it's a readonly operation).
> >
> > If you are able to patch and build a kernel, you can also try the
> > patch. I left it running tests overnight and haven't got any
> > regressions.
> >
> > Thanks.
> >
> > > On Sat, Oct 20, 2018 at 10:02 PM Andrew Nelson
> > > <andrew.s.nelson@gmail.com> wrote:
> > > >
> > > > I have ran the "btrfs inspect-internal dump-tree -t 1" command, but
> > > > the output is ~55mb. Is there something in particular you are looking
> > > > for in this?
> > > > On Sat, Oct 20, 2018 at 1:34 PM Filipe Manana <fdmanana@gmail.com> wrote:
> > > > >
> > > > > On Sat, Oct 20, 2018 at 9:27 PM Liu Bo <obuil.liubo@gmail.com> wrote:
> > > > > >
> > > > > > On Fri, Oct 19, 2018 at 7:09 PM Andrew Nelson <andrew.s.nelson@gmail.com> wrote:
> > > > > > >
> > > > > > > I am having an issue with btrfs resize in Fedora 28. I am attempting
> > > > > > > to enlarge my Btrfs partition. Every time I run "btrfs filesystem
> > > > > > > resize max $MOUNT", the command runs for a few minutes and then hangs
> > > > > > > forcing the system to be reset. I am not sure what the state of the
> > > > > > > filesystem really is at this point. Btrfs usage does report the
> > > > > > > correct size for after resizing. Details below:
> > > > > > >
> > > > > >
> > > > > > Thanks for the report, the stack is helpful, but this needs a few
> > > > > > deeper debugging, may I ask you to post "btrfs inspect-internal
> > > > > > dump-tree -t 1 /dev/your_btrfs_disk"?
> > > > >
> > > > > I believe it's actually easy to understand from the trace alone and
> > > > > it's kind of a bad luck scenario.
> > > > > I made this fix a few hours ago:
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git/commit/?h=fix_find_free_extent_deadlock
> > > > >
> > > > > But haven't done full testing yet and might have missed something.
> > > > > Bo, can you take a look and let me know what you think?
> > > > >
> > > > > Thanks.
> > > > >
> > > > > >
> > > > > > So I'd like to know what's the height of your tree "1" which refers to
> > > > > > root tree in btrfs.
> > > > > >
> > > > > > thanks,
> > > > > > liubo
> > > > > >
> > > > > > > $ sudo btrfs filesystem usage $MOUNT
> > > > > > > Overall:
> > > > > > > Device size: 90.96TiB
> > > > > > > Device allocated: 72.62TiB
> > > > > > > Device unallocated: 18.33TiB
> > > > > > > Device missing: 0.00B
> > > > > > > Used: 72.62TiB
> > > > > > > Free (estimated): 18.34TiB (min: 9.17TiB)
> > > > > > > Data ratio: 1.00
> > > > > > > Metadata ratio: 2.00
> > > > > > > Global reserve: 512.00MiB (used: 24.11MiB)
> > > > > > >
> > > > > > > Data,single: Size:72.46TiB, Used:72.45TiB
> > > > > > > $MOUNT 72.46TiB
> > > > > > >
> > > > > > > Metadata,DUP: Size:86.00GiB, Used:84.96GiB
> > > > > > > $MOUNT 172.00GiB
> > > > > > >
> > > > > > > System,DUP: Size:40.00MiB, Used:7.53MiB
> > > > > > > $MOUNT 80.00MiB
> > > > > > >
> > > > > > > Unallocated:
> > > > > > > $MOUNT 18.33TiB
> > > > > > >
> > > > > > > $ uname -a
> > > > > > > Linux localhost.localdomain 4.18.14-200.fc28.x86_64 #1 SMP Mon Oct 15
> > > > > > > 13:16:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> > > > > > >
> > > > > > > btrfs-transacti D 0 2501 2 0x80000000
> > > > > > > Call Trace:
> > > > > > > ? __schedule+0x253/0x860
> > > > > > > schedule+0x28/0x80
> > > > > > > btrfs_commit_transaction+0x7aa/0x8b0 [btrfs]
> > > > > > > ? kmem_cache_alloc+0x166/0x1d0
> > > > > > > ? join_transaction+0x22/0x3e0 [btrfs]
> > > > > > > ? finish_wait+0x80/0x80
> > > > > > > transaction_kthread+0x155/0x170 [btrfs]
> > > > > > > ? btrfs_cleanup_transaction+0x550/0x550 [btrfs]
> > > > > > > kthread+0x112/0x130
> > > > > > > ? kthread_create_worker_on_cpu+0x70/0x70
> > > > > > > ret_from_fork+0x35/0x40
> > > > > > > btrfs D 0 2504 2502 0x00000002
> > > > > > > Call Trace:
> > > > > > > ? __schedule+0x253/0x860
> > > > > > > schedule+0x28/0x80
> > > > > > > btrfs_tree_read_lock+0x8e/0x120 [btrfs]
> > > > > > > ? finish_wait+0x80/0x80
> > > > > > > btrfs_read_lock_root_node+0x2f/0x40 [btrfs]
> > > > > > > btrfs_search_slot+0xf6/0x9f0 [btrfs]
> > > > > > > ? evict_refill_and_join+0xd0/0xd0 [btrfs]
> > > > > > > ? inode_insert5+0x119/0x190
> > > > > > > btrfs_lookup_inode+0x3a/0xc0 [btrfs]
> > > > > > > ? kmem_cache_alloc+0x166/0x1d0
> > > > > > > btrfs_iget+0x113/0x690 [btrfs]
> > > > > > > __lookup_free_space_inode+0xd8/0x150 [btrfs]
> > > > > > > lookup_free_space_inode+0x5b/0xb0 [btrfs]
> > > > > > > load_free_space_cache+0x7c/0x170 [btrfs]
> > > > > > > ? cache_block_group+0x72/0x3b0 [btrfs]
> > > > > > > cache_block_group+0x1b3/0x3b0 [btrfs]
> > > > > > > ? finish_wait+0x80/0x80
> > > > > > > find_free_extent+0x799/0x1010 [btrfs]
> > > > > > > btrfs_reserve_extent+0x9b/0x180 [btrfs]
> > > > > > > btrfs_alloc_tree_block+0x1b3/0x4f0 [btrfs]
> > > > > > > __btrfs_cow_block+0x11d/0x500 [btrfs]
> > > > > > > btrfs_cow_block+0xdc/0x180 [btrfs]
> > > > > > > btrfs_search_slot+0x3bd/0x9f0 [btrfs]
> > > > > > > btrfs_lookup_inode+0x3a/0xc0 [btrfs]
> > > > > > > ? kmem_cache_alloc+0x166/0x1d0
> > > > > > > btrfs_update_inode_item+0x46/0x100 [btrfs]
> > > > > > > cache_save_setup+0xe4/0x3a0 [btrfs]
> > > > > > > btrfs_start_dirty_block_groups+0x1be/0x480 [btrfs]
> > > > > > > btrfs_commit_transaction+0xcb/0x8b0 [btrfs]
> > > > > > > ? btrfs_release_path+0x13/0x80 [btrfs]
> > > > > > > ? btrfs_update_device+0x8d/0x1c0 [btrfs]
> > > > > > > btrfs_ioctl_resize.cold.46+0xf4/0xf9 [btrfs]
> > > > > > > btrfs_ioctl+0xa25/0x2cf0 [btrfs]
> > > > > > > ? tty_write+0x1fc/0x330
> > > > > > > ? do_vfs_ioctl+0xa4/0x620
> > > > > > > do_vfs_ioctl+0xa4/0x620
> > > > > > > ksys_ioctl+0x60/0x90
> > > > > > > ? ksys_write+0x4f/0xb0
> > > > > > > __x64_sys_ioctl+0x16/0x20
> > > > > > > do_syscall_64+0x5b/0x160
> > > > > > > entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > > > > > RIP: 0033:0x7fcdc0d78c57
> > > > > > > Code: Bad RIP value.
> > > > > > > RSP: 002b:00007ffdd1ee6cf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> > > > > > > RAX: ffffffffffffffda RBX: 00007ffdd1ee888a RCX: 00007fcdc0d78c57
> > > > > > > RDX: 00007ffdd1ee6da0 RSI: 0000000050009403 RDI: 0000000000000003
> > > > > > > RBP: 00007ffdd1ee6da0 R08: 0000000000000000 R09: 00007ffdd1ee67e0
> > > > > > > R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffdd1ee888e
> > > > > > > R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
> > > > > > > kworker/u48:1 D 0 2505 2 0x80000000
> > > > > > > Workqueue: btrfs-freespace-write btrfs_freespace_write_helper [btrfs]
> > > > > > > Call Trace:
> > > > > > > ? __schedule+0x253/0x860
> > > > > > > schedule+0x28/0x80
> > > > > > > btrfs_tree_lock+0x130/0x210 [btrfs]
> > > > > > > ? finish_wait+0x80/0x80
> > > > > > > btrfs_search_slot+0x775/0x9f0 [btrfs]
> > > > > > > btrfs_mark_extent_written+0xb0/0xb20 [btrfs]
> > > > > > > ? join_transaction+0x22/0x3e0 [btrfs]
> > > > > > > btrfs_finish_ordered_io+0x2e0/0x7e0 [btrfs]
> > > > > > > ? syscall_return_via_sysret+0x13/0x83
> > > > > > > ? __switch_to_asm+0x34/0x70
> > > > > > > normal_work_helper+0xd3/0x2f0 [btrfs]
> > > > > > > process_one_work+0x1a1/0x350
> > > > > > > worker_thread+0x30/0x380
> > > > > > > ? pwq_unbound_release_workfn+0xd0/0xd0
> > > > > > > kthread+0x112/0x130
> > > > > > > ? kthread_create_worker_on_cpu+0x70/0x70
> > > > > > > ret_from_fork+0x35/0x40
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Filipe David Manana,
> > > > >
> > > > > “Whether you think you can, or you think you can't — you're right.”
> >
> >
> >
> > --
> > Filipe David Manana,
> >
> > “Whether you think you can, or you think you can't — you're right.”
--
Filipe David Manana,
“Whether you think you can, or you think you can't — you're right.”
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Btrfs resize seems to deadlock
2018-10-20 20:34 ` Filipe Manana
2018-10-21 5:02 ` Andrew Nelson
@ 2018-10-23 0:18 ` Liu Bo
1 sibling, 0 replies; 9+ messages in thread
From: Liu Bo @ 2018-10-23 0:18 UTC (permalink / raw)
To: Filipe Manana; +Cc: Andrew Nelson, linux-btrfs
On Sat, Oct 20, 2018 at 1:34 PM Filipe Manana <fdmanana@gmail.com> wrote:
>
> On Sat, Oct 20, 2018 at 9:27 PM Liu Bo <obuil.liubo@gmail.com> wrote:
> >
> > On Fri, Oct 19, 2018 at 7:09 PM Andrew Nelson <andrew.s.nelson@gmail.com> wrote:
> > >
> > > I am having an issue with btrfs resize in Fedora 28. I am attempting
> > > to enlarge my Btrfs partition. Every time I run "btrfs filesystem
> > > resize max $MOUNT", the command runs for a few minutes and then hangs
> > > forcing the system to be reset. I am not sure what the state of the
> > > filesystem really is at this point. Btrfs usage does report the
> > > correct size for after resizing. Details below:
> > >
> >
> > Thanks for the report, the stack is helpful, but this needs a few
> > deeper debugging, may I ask you to post "btrfs inspect-internal
> > dump-tree -t 1 /dev/your_btrfs_disk"?
>
> I believe it's actually easy to understand from the trace alone and
> it's kind of a bad luck scenario.
> I made this fix a few hours ago:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git/commit/?h=fix_find_free_extent_deadlock
>
> But haven't done full testing yet and might have missed something.
> Bo, can you take a look and let me know what you think?
>
The patch is OK to me, should fix the problem.
Since load_free_space_cache() is touching root tree with
path->commit_root and skip_locking, I was wondering if we could just
provide a same way for free space cache inode's iget().
thanks,
liubo
> Thanks.
>
> >
> > So I'd like to know what's the height of your tree "1" which refers to
> > root tree in btrfs.
> >
> > thanks,
> > liubo
> >
> > > $ sudo btrfs filesystem usage $MOUNT
> > > Overall:
> > > Device size: 90.96TiB
> > > Device allocated: 72.62TiB
> > > Device unallocated: 18.33TiB
> > > Device missing: 0.00B
> > > Used: 72.62TiB
> > > Free (estimated): 18.34TiB (min: 9.17TiB)
> > > Data ratio: 1.00
> > > Metadata ratio: 2.00
> > > Global reserve: 512.00MiB (used: 24.11MiB)
> > >
> > > Data,single: Size:72.46TiB, Used:72.45TiB
> > > $MOUNT 72.46TiB
> > >
> > > Metadata,DUP: Size:86.00GiB, Used:84.96GiB
> > > $MOUNT 172.00GiB
> > >
> > > System,DUP: Size:40.00MiB, Used:7.53MiB
> > > $MOUNT 80.00MiB
> > >
> > > Unallocated:
> > > $MOUNT 18.33TiB
> > >
> > > $ uname -a
> > > Linux localhost.localdomain 4.18.14-200.fc28.x86_64 #1 SMP Mon Oct 15
> > > 13:16:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> > >
> > > btrfs-transacti D 0 2501 2 0x80000000
> > > Call Trace:
> > > ? __schedule+0x253/0x860
> > > schedule+0x28/0x80
> > > btrfs_commit_transaction+0x7aa/0x8b0 [btrfs]
> > > ? kmem_cache_alloc+0x166/0x1d0
> > > ? join_transaction+0x22/0x3e0 [btrfs]
> > > ? finish_wait+0x80/0x80
> > > transaction_kthread+0x155/0x170 [btrfs]
> > > ? btrfs_cleanup_transaction+0x550/0x550 [btrfs]
> > > kthread+0x112/0x130
> > > ? kthread_create_worker_on_cpu+0x70/0x70
> > > ret_from_fork+0x35/0x40
> > > btrfs D 0 2504 2502 0x00000002
> > > Call Trace:
> > > ? __schedule+0x253/0x860
> > > schedule+0x28/0x80
> > > btrfs_tree_read_lock+0x8e/0x120 [btrfs]
> > > ? finish_wait+0x80/0x80
> > > btrfs_read_lock_root_node+0x2f/0x40 [btrfs]
> > > btrfs_search_slot+0xf6/0x9f0 [btrfs]
> > > ? evict_refill_and_join+0xd0/0xd0 [btrfs]
> > > ? inode_insert5+0x119/0x190
> > > btrfs_lookup_inode+0x3a/0xc0 [btrfs]
> > > ? kmem_cache_alloc+0x166/0x1d0
> > > btrfs_iget+0x113/0x690 [btrfs]
> > > __lookup_free_space_inode+0xd8/0x150 [btrfs]
> > > lookup_free_space_inode+0x5b/0xb0 [btrfs]
> > > load_free_space_cache+0x7c/0x170 [btrfs]
> > > ? cache_block_group+0x72/0x3b0 [btrfs]
> > > cache_block_group+0x1b3/0x3b0 [btrfs]
> > > ? finish_wait+0x80/0x80
> > > find_free_extent+0x799/0x1010 [btrfs]
> > > btrfs_reserve_extent+0x9b/0x180 [btrfs]
> > > btrfs_alloc_tree_block+0x1b3/0x4f0 [btrfs]
> > > __btrfs_cow_block+0x11d/0x500 [btrfs]
> > > btrfs_cow_block+0xdc/0x180 [btrfs]
> > > btrfs_search_slot+0x3bd/0x9f0 [btrfs]
> > > btrfs_lookup_inode+0x3a/0xc0 [btrfs]
> > > ? kmem_cache_alloc+0x166/0x1d0
> > > btrfs_update_inode_item+0x46/0x100 [btrfs]
> > > cache_save_setup+0xe4/0x3a0 [btrfs]
> > > btrfs_start_dirty_block_groups+0x1be/0x480 [btrfs]
> > > btrfs_commit_transaction+0xcb/0x8b0 [btrfs]
> > > ? btrfs_release_path+0x13/0x80 [btrfs]
> > > ? btrfs_update_device+0x8d/0x1c0 [btrfs]
> > > btrfs_ioctl_resize.cold.46+0xf4/0xf9 [btrfs]
> > > btrfs_ioctl+0xa25/0x2cf0 [btrfs]
> > > ? tty_write+0x1fc/0x330
> > > ? do_vfs_ioctl+0xa4/0x620
> > > do_vfs_ioctl+0xa4/0x620
> > > ksys_ioctl+0x60/0x90
> > > ? ksys_write+0x4f/0xb0
> > > __x64_sys_ioctl+0x16/0x20
> > > do_syscall_64+0x5b/0x160
> > > entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > RIP: 0033:0x7fcdc0d78c57
> > > Code: Bad RIP value.
> > > RSP: 002b:00007ffdd1ee6cf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> > > RAX: ffffffffffffffda RBX: 00007ffdd1ee888a RCX: 00007fcdc0d78c57
> > > RDX: 00007ffdd1ee6da0 RSI: 0000000050009403 RDI: 0000000000000003
> > > RBP: 00007ffdd1ee6da0 R08: 0000000000000000 R09: 00007ffdd1ee67e0
> > > R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffdd1ee888e
> > > R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
> > > kworker/u48:1 D 0 2505 2 0x80000000
> > > Workqueue: btrfs-freespace-write btrfs_freespace_write_helper [btrfs]
> > > Call Trace:
> > > ? __schedule+0x253/0x860
> > > schedule+0x28/0x80
> > > btrfs_tree_lock+0x130/0x210 [btrfs]
> > > ? finish_wait+0x80/0x80
> > > btrfs_search_slot+0x775/0x9f0 [btrfs]
> > > btrfs_mark_extent_written+0xb0/0xb20 [btrfs]
> > > ? join_transaction+0x22/0x3e0 [btrfs]
> > > btrfs_finish_ordered_io+0x2e0/0x7e0 [btrfs]
> > > ? syscall_return_via_sysret+0x13/0x83
> > > ? __switch_to_asm+0x34/0x70
> > > normal_work_helper+0xd3/0x2f0 [btrfs]
> > > process_one_work+0x1a1/0x350
> > > worker_thread+0x30/0x380
> > > ? pwq_unbound_release_workfn+0xd0/0xd0
> > > kthread+0x112/0x130
> > > ? kthread_create_worker_on_cpu+0x70/0x70
> > > ret_from_fork+0x35/0x40
>
>
>
> --
> Filipe David Manana,
>
> “Whether you think you can, or you think you can't — you're right.”
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-10-23 0:19 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-20 2:05 Btrfs resize seems to deadlock Andrew Nelson
2018-10-20 20:23 ` Liu Bo
2018-10-20 20:34 ` Filipe Manana
2018-10-21 5:02 ` Andrew Nelson
2018-10-21 5:05 ` Andrew Nelson
2018-10-21 8:56 ` Filipe Manana
2018-10-22 9:06 ` Andrew Nelson
2018-10-22 9:12 ` Filipe Manana
2018-10-23 0:18 ` Liu Bo
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.