FS#41155 - [linux] btrfs deadlock

Attached to Project: Arch Linux
Opened by Ben Meier (derb3r) - Thursday, 10 July 2014, 06:08 GMT
Last edited by Tobias Powalowski (tpowa) - Friday, 11 July 2014, 05:06 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

DESC:

If I simply try to extract a tar or even if I run VMware Workstation with a Win 7 VM my load average is very high and system starts hanging:

top - 06:52:54 up 15 min, 0 users, load average: 8,98, 6,95, 3,89
Tasks: 264 total, 1 running, 262 sleeping, 0 stopped, 1 zombie
%Cpu(s): 2,4 us, 14,8 sy, 0,0 ni, 8,1 id, 74,6 wa, 0,0 hi, 0,2 si, 0,0 st
KiB Mem: 7753072 total, 7639536 used, 113536 free, 32 buffers
KiB Swap: 4194300 total, 8 used, 4194292 free. 6392064 cached Mem

Additional info:
* Linux wn2013601481 3.15.4-1-ARCH #1 SMP PREEMPT Mon Jul 7 07:42:54 CEST 2014 x86_64 GNU/Linux
* btrfs-progs 3.14.2-2
* my CPU: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz

ACTION:

After that I have start reading logs and found deadloc situation with btrfs filesystem. Asking mr google let me find:

https://patchwork.kernel.org/patch/4143821/

I am not sure if this is exact my case but maybe it helps to analyze

journalctl:

Jul 10 06:43:29 wn2013601481 kernel: INFO: task kworker/u16:6:122 blocked for more than 120 seconds.
Jul 10 06:43:29 wn2013601481 kernel: Tainted: G O 3.15.4-1-ARCH #1
Jul 10 06:43:29 wn2013601481 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jul 10 06:43:29 wn2013601481 kernel: kworker/u16:6 D 0000000000000000 0 122 2 0x00000000
Jul 10 06:43:29 wn2013601481 kernel: Workqueue: writeback bdi_writeback_workfn (flush-btrfs-2)
Jul 10 06:43:29 wn2013601481 kernel: ffff88021215f9b8 0000000000000046 ffff88003712bd20 0000000000014700
Jul 10 06:43:29 wn2013601481 kernel: ffff88021215ffd8 0000000000014700 ffff88003712bd20 ffffffffa05df672
Jul 10 06:43:29 wn2013601481 kernel: 0000000000000000 ffffffff00000050 ffff88021215fa34 ffff88021215f938
Jul 10 06:43:29 wn2013601481 kernel: Call Trace:
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffffa05df672>] ? run_delalloc_range+0x192/0x350 [btrfs]
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff8101ce09>] ? read_tsc+0x9/0x20
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff810d49d8>] ? ktime_get_ts+0x48/0xf0
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff810fed95>] ? delayacct_end+0x95/0xc0
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff8113f850>] ? filemap_fdatawait+0x30/0x30
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff81509f59>] schedule+0x29/0x70
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff8150a244>] io_schedule+0x94/0xf0
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff8113f85e>] sleep_on_page+0xe/0x20
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff8150a738>] __wait_on_bit_lock+0x48/0xb0
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff8113f9b8>] __lock_page+0x78/0x90
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff810b1c80>] ? autoremove_wake_function+0x40/0x40
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffffa05f7c78>] extent_write_cache_pages.isra.28.constprop.45+0x258/0x3a0 [btrfs]
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffffa05f91ec>] extent_writepages+0x5c/0x90 [btrfs]
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffffa05db9b0>] ? __btrfs_submit_bio_start_direct_io+0x40/0x40 [btrfs]
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffffa05da6c8>] btrfs_writepages+0x28/0x30 [btrfs]
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff8114d08e>] do_writepages+0x1e/0x30
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff811df1c0>] __writeback_single_inode+0x40/0x2b0
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff811e06ca>] writeback_sb_inodes+0x26a/0x430
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff811e092f>] __writeback_inodes_wb+0x9f/0xd0
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff811e0b8b>] wb_writeback+0x22b/0x360
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff8114bd70>] ? bdi_dirty_limit+0x40/0xe0
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff811e100c>] bdi_writeback_workfn+0x1ec/0x4c0
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff810861d8>] process_one_work+0x168/0x450
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff81086c32>] worker_thread+0x132/0x3e0
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff81086b00>] ? manage_workers.isra.23+0x2d0/0x2d0
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff8108d43a>] kthread+0xea/0x100
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff8108d350>] ? kthread_create_on_node+0x1b0/0x1b0
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff81515ebc>] ret_from_fork+0x7c/0xb0
Jul 10 06:43:29 wn2013601481 kernel: [<ffffffff8108d350>] ? kthread_create_on_node+0x1b0/0x1b0
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Friday, 11 July 2014, 05:06 GMT
Reason for closing:  Upstream
Comment by Tobias Powalowski (tpowa) - Thursday, 10 July 2014, 07:13 GMT
Please get in touch with btrfs developers, expect you get help on their irc channels and mailinglists.
Comment by Ben Meier (derb3r) - Friday, 11 July 2014, 05:02 GMT
After mount filesystem without compress=lzo which seems to be a bug at the moment in btrfs the load average fall back to 0.1 ~ 0.2 to normal state. So Please close this case I will wait until a fix comes up from btrfs developers

Loading...