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
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
|
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
Comment by
Tobias Powalowski (tpowa) - Thursday,
10 July 2014, 07:13 GMT
Comment by Ben Meier (derb3r) -
Friday, 11 July 2014, 05:02 GMT
Please get in touch with btrfs developers, expect you get help on
their irc channels and mailinglists.
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