Re: Blocked for more than 120 seconds
On Sat, Dec 03, 2011 at 04:36:44PM +0200, Konstantinos Skarlatos wrote: unfortunately i was wrong. rc4 does not fix this issue for me when rsyncing large amounts of data... my mount options: mount -o loop,compress=zlib,compress-force btrfs_test /storage/btrfs the filesystem is a file on a raid5 xfs volume. Oh, the loop + raid5 + xfs is going to cause problems. The loop driver is fine for testing but I wouldn't be using it in a production environment. -chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Blocked for more than 120 seconds
even more kernel messages from btrfs crashing when rsyncing large amounts of data on 3.2rc4 Dec 3 15:12:14 mail kernel: [15481.100564] loop0 D 00010044b6c5 0 1729 2 0x Dec 3 15:12:14 mail kernel: [15481.101550] 8801f9b31b30 0046 Dec 3 15:12:14 mail kernel: [15481.102548] 880200950e40 8801f9b31fd8 8801f9b31fd8 8801f9b31fd8 Dec 3 15:12:14 mail kernel: [15481.103539] 880202cb7200 880200950e40 0002 8801f9b31b78 Dec 3 15:12:14 mail kernel: [15481.104533] Call Trace: Dec 3 15:12:14 mail kernel: [15481.105531] [81101a55] ? find_get_pages_tag+0x125/0x150 Dec 3 15:12:14 mail kernel: [15481.106541] [8110e205] ? pagevec_lookup_tag+0x25/0x40 Dec 3 15:12:14 mail kernel: [15481.107552] [8101d639] ? read_tsc+0x9/0x20 Dec 3 15:12:14 mail kernel: [15481.108576] [8108f14d] ? ktime_get_ts+0xad/0xe0 Dec 3 15:12:14 mail kernel: [15481.109592] [81101d60] ? __lock_page+0x70/0x70 Dec 3 15:12:14 mail kernel: [15481.110607] [814140bf] schedule+0x3f/0x60 Dec 3 15:12:14 mail kernel: [15481.111619] [8141416f] io_schedule+0x8f/0xd0 Dec 3 15:12:14 mail kernel: [15481.112641] [81101d6e] sleep_on_page+0xe/0x20 Dec 3 15:12:14 mail kernel: [15481.113639] [8141491f] __wait_on_bit+0x5f/0x90 Dec 3 15:12:14 mail kernel: [15481.114629] [81101f58] wait_on_page_bit+0x78/0x80 Dec 3 15:12:14 mail kernel: [15481.115628] [81085790] ? autoremove_wake_function+0x40/0x40 Dec 3 15:12:14 mail kernel: [15481.116614] [811020cc] filemap_fdatawait_range+0x10c/0x1a0 Dec 3 15:12:14 mail kernel: [15481.117613] [811030c8] filemap_write_and_wait_range+0x68/0x80 Dec 3 15:12:14 mail kernel: [15481.118630] [a03a7234] xfs_file_fsync+0x54/0x340 [xfs] Dec 3 15:12:14 mail kernel: [15481.119629] [8119148b] vfs_fsync+0x2b/0x40 Dec 3 15:12:14 mail kernel: [15481.120627] [a04dacf2] do_bio_filebacked+0x1b2/0x320 [loop] Dec 3 15:12:14 mail kernel: [15481.121645] [a050efac] ? end_workqueue_bio+0x9c/0xa0 [btrfs] Dec 3 15:12:14 mail kernel: [15481.122668] [a04daf1b] loop_thread+0xbb/0x260 [loop] Dec 3 15:12:14 mail kernel: [15481.123674] [81085750] ? abort_exclusive_wait+0xb0/0xb0 Dec 3 15:12:14 mail kernel: [15481.124676] [a04dae60] ? do_bio_filebacked+0x320/0x320 [loop] Dec 3 15:12:14 mail kernel: [15481.125698] [81084e0c] kthread+0x8c/0xa0 Dec 3 15:12:14 mail kernel: [15481.126710] [81419a34] kernel_thread_helper+0x4/0x10 Dec 3 15:12:14 mail kernel: [15481.127721] [81084d80] ? kthread_worker_fn+0x190/0x190 Dec 3 15:12:14 mail kernel: [15481.128742] [81419a30] ? gs_change+0x13/0x13 Dec 3 15:12:14 mail kernel: [15481.131702] btrfs-transacti D 8801f9ab7200 0 1756 2 0x Dec 3 15:12:14 mail kernel: [15481.132723] 8801e7533bc0 0046 88020fc93400 0002 Dec 3 15:12:14 mail kernel: [15481.133744] 8801f9ab7200 8801e7533fd8 8801e7533fd8 8801e7533fd8 Dec 3 15:12:14 mail kernel: [15481.134771] 880200950e40 8801f9ab7200 8801e7533b10 81051ae2 Dec 3 15:12:14 mail kernel: [15481.135813] Call Trace: Dec 3 15:12:14 mail kernel: [15481.136828] [8105ad36] ? ttwu_do_activate.constprop.172+0x66/0x70 Dec 3 15:12:14 mail kernel: [15481.137863] [8105bd6e] ? try_to_wake_up+0x1de/0x290 Dec 3 15:12:14 mail kernel: [15481.138914] [814140bf] schedule+0x3f/0x60 Dec 3 15:12:14 mail kernel: [15481.139956] [814147d5] schedule_timeout+0x305/0x390 Dec 3 15:12:14 mail kernel: [15481.141007] [8104d003] ? __wake_up+0x53/0x70 Dec 3 15:12:14 mail kernel: [15481.142074] [81413348] wait_for_common+0xc8/0x160 Dec 3 15:12:14 mail kernel: [15481.143124] [8105be20] ? try_to_wake_up+0x290/0x290 Dec 3 15:12:14 mail kernel: [15481.144170] [814133fd] wait_for_completion+0x1d/0x20 Dec 3 15:12:14 mail kernel: [15481.145229] [a050f0bb] write_dev_flush+0x4b/0x140 [btrfs] Dec 3 15:12:14 mail kernel: [15481.146275] [a0511086] write_all_supers+0x6f6/0x800 [btrfs] Dec 3 15:12:14 mail kernel: [15481.147317] [a05111a3] write_ctree_super+0x13/0x20 [btrfs] Dec 3 15:12:14 mail kernel: [15481.148354] [a05164dd] btrfs_commit_transaction+0x63d/0x880 [btrfs] Dec 3 15:12:14 mail kernel: [15481.149397] [81085750] ? abort_exclusive_wait+0xb0/0xb0 Dec 3 15:12:14 mail kernel: [15481.150416] [a0516b74] ? start_transaction+0x94/0x2b0 [btrfs] Dec 3 15:12:14 mail kernel: [15481.151444] [a050ed4d] transaction_kthread+0x26d/0x290 [btrfs] Dec 3 15:12:14 mail kernel: [15481.152492] [a050eae0] ? btrfs_congested_fn+0xd0/0xd0 [btrfs] Dec 3 15:12:14 mail kernel: [15481.153519]
Re: Blocked for more than 120 seconds
unfortunately i was wrong. rc4 does not fix this issue for me when rsyncing large amounts of data... my mount options: mount -o loop,compress=zlib,compress-force btrfs_test /storage/btrfs the filesystem is a file on a raid5 xfs volume. [15481.098588] INFO: task loop0:1729 blocked for more than 120 seconds. [15481.099571] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [15481.100564] loop0 D 00010044b6c5 0 1729 2 0x [15481.101550] 8801f9b31b30 0046 [15481.102548] 880200950e40 8801f9b31fd8 8801f9b31fd8 8801f9b31fd8 [15481.103539] 880202cb7200 880200950e40 0002 8801f9b31b78 [15481.104533] Call Trace: [15481.105531] [81101a55] ? find_get_pages_tag+0x125/0x150 [15481.106541] [8110e205] ? pagevec_lookup_tag+0x25/0x40 [15481.107552] [8101d639] ? read_tsc+0x9/0x20 [15481.108576] [8108f14d] ? ktime_get_ts+0xad/0xe0 [15481.109592] [81101d60] ? __lock_page+0x70/0x70 [15481.110607] [814140bf] schedule+0x3f/0x60 [15481.111619] [8141416f] io_schedule+0x8f/0xd0 [15481.112641] [81101d6e] sleep_on_page+0xe/0x20 [15481.113639] [8141491f] __wait_on_bit+0x5f/0x90 [15481.114629] [81101f58] wait_on_page_bit+0x78/0x80 [15481.115628] [81085790] ? autoremove_wake_function+0x40/0x40 [15481.116614] [811020cc] filemap_fdatawait_range+0x10c/0x1a0 [15481.117613] [811030c8] filemap_write_and_wait_range+0x68/0x80 [15481.118630] [a03a7234] xfs_file_fsync+0x54/0x340 [xfs] [15481.119629] [8119148b] vfs_fsync+0x2b/0x40 [15481.120627] [a04dacf2] do_bio_filebacked+0x1b2/0x320 [loop] [15481.121645] [a050efac] ? end_workqueue_bio+0x9c/0xa0 [btrfs] [15481.122668] [a04daf1b] loop_thread+0xbb/0x260 [loop] [15481.123674] [81085750] ? abort_exclusive_wait+0xb0/0xb0 [15481.124676] [a04dae60] ? do_bio_filebacked+0x320/0x320 [loop] [15481.125698] [81084e0c] kthread+0x8c/0xa0 [15481.126710] [81419a34] kernel_thread_helper+0x4/0x10 [15481.127721] [81084d80] ? kthread_worker_fn+0x190/0x190 [15481.128742] [81419a30] ? gs_change+0x13/0x13 [15481.129728] INFO: task btrfs-transacti:1756 blocked for more than 120 seconds. [15481.130706] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [15481.131702] btrfs-transacti D 8801f9ab7200 0 1756 2 0x [15481.132723] 8801e7533bc0 0046 88020fc93400 0002 [15481.133744] 8801f9ab7200 8801e7533fd8 8801e7533fd8 8801e7533fd8 [15481.134771] 880200950e40 8801f9ab7200 8801e7533b10 81051ae2 [15481.135813] Call Trace: [15481.136828] [8105ad36] ? ttwu_do_activate.constprop.172+0x66/0x70 [15481.137863] [8105bd6e] ? try_to_wake_up+0x1de/0x290 [15481.138914] [814140bf] schedule+0x3f/0x60 [15481.139956] [814147d5] schedule_timeout+0x305/0x390 [15481.141007] [8104d003] ? __wake_up+0x53/0x70 [15481.142074] [81413348] wait_for_common+0xc8/0x160 [15481.143124] [8105be20] ? try_to_wake_up+0x290/0x290 [15481.144170] [814133fd] wait_for_completion+0x1d/0x20 [15481.145229] [a050f0bb] write_dev_flush+0x4b/0x140 [btrfs] [15481.146275] [a0511086] write_all_supers+0x6f6/0x800 [btrfs] [15481.147317] [a05111a3] write_ctree_super+0x13/0x20 [btrfs] [15481.148354] [a05164dd] btrfs_commit_transaction+0x63d/0x880 [btrfs] [15481.149397] [81085750] ? abort_exclusive_wait+0xb0/0xb0 [15481.150416] [a0516b74] ? start_transaction+0x94/0x2b0 [btrfs] [15481.151444] [a050ed4d] transaction_kthread+0x26d/0x290 [btrfs] [15481.152492] [a050eae0] ? btrfs_congested_fn+0xd0/0xd0 [btrfs] [15481.153519] [81084e0c] kthread+0x8c/0xa0 [15481.154542] [81419a34] kernel_thread_helper+0x4/0x10 [15481.13] [81084d80] ? kthread_worker_fn+0x190/0x190 [15481.156522] [81419a30] ? gs_change+0x13/0x13 [15481.157501] INFO: task smbd:2058 blocked for more than 120 seconds. [15481.158513] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [15481.159519] smbdD 00010044b8d7 0 2058823 0x0004 [15481.160544] 88005cf37a08 0082 88005cf37938 81371188 [15481.161588] 8802012e63c0 88005cf37fd8 88005cf37fd8 88005cf37fd8 [15481.162658] 880202d21c80 8802012e63c0 8802012769c0 0246 [15481.163708] Call Trace: [15481.164736] [81371188] ? sch_direct_xmit+0x68/0x1d0 [15481.165781] [81355a00] ? dev_queue_xmit+0x200/0x680 [15481.166805] [81389200] ? ip_forward_options+0x1c0/0x1c0 [15481.167822] [8138adbe] ? ip_finish_output+0x18e/0x310 [15481.168850]
Re: Blocked for more than 120 seconds
Hi Chris! Am 01.12.2011 19:41, schrieb Chris Mason: So, the transaction close is in btrfs_evict_inode, which sounds like a deadlock recently fixed by this commit: http://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=aa38a711a893accf5b5192f3d705a120deaa81e0 If you pull the for-linus branch from today, hopefully the problem will be gone. This looks very good. With this Kernel i still have some hangs, but only in rsync, only under high load and they don't lock up the system - so i guess it's ok now. Thank You very much for Your help! When will this patches go into the main Kernel? Tobias -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Blocked for more than 120 seconds
On Fri, Dec 02, 2011 at 02:46:48PM +0100, Tobias wrote: Hi Chris! Am 01.12.2011 19:41, schrieb Chris Mason: So, the transaction close is in btrfs_evict_inode, which sounds like a deadlock recently fixed by this commit: http://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=aa38a711a893accf5b5192f3d705a120deaa81e0 If you pull the for-linus branch from today, hopefully the problem will be gone. This looks very good. With this Kernel i still have some hangs, but only in rsync, only under high load and they don't lock up the system - so i guess it's ok now. Thank You very much for Your help! Glad to hear this is working. All the credit to Miao, who found the deadlock. When will this patches go into the main Kernel? Linus pulled them in yesterday. -chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Blocked for more than 120 seconds
Hi all On 2/12/2011 3:46 μμ, Tobias wrote: Hi Chris! Am 01.12.2011 19:41, schrieb Chris Mason: So, the transaction close is in btrfs_evict_inode, which sounds like a deadlock recently fixed by this commit: http://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=aa38a711a893accf5b5192f3d705a120deaa81e0 If you pull the for-linus branch from today, hopefully the problem will be gone. This looks very good. With this Kernel i still have some hangs, but only in rsync, only under high load and they don't lock up the system - so i guess it's ok now. I still have hangs and lock ups under the same situation (rsync of many files) under 3.2rc3. rc3 made the hang appear after 200gb of files, while in rc2 i had hangs after only 11gb . Thank You very much for Your help! When will this patches go into the main Kernel? Tobias -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Blocked for more than 120 seconds
Am 02.12.2011 16:22, schrieb Konstantinos Skarlatos: So, the transaction close is in btrfs_evict_inode, which sounds like a deadlock recently fixed by this commit: http://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=aa38a711a893accf5b5192f3d705a120deaa81e0 If you pull the for-linus branch from today, hopefully the problem will be gone. This looks very good. With this Kernel i still have some hangs, but only in rsync, only under high load and they don't lock up the system - so i guess it's ok now. I still have hangs and lock ups under the same situation (rsync of many files) under 3.2rc3. rc3 made the hang appear after 200gb of files, while in rc2 i had hangs after only 11gb . Yes, i had them too in 3.2rc3! The problem where solved with patches from the btrfs-for-linus -branch. (see link above). Tobias -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Blocked for more than 120 seconds
I see they got into 3.2rc4, so I am now compiling it. I will report back in a few hours On Παρασκευή, 2 Δεκέμβριος 2011 5:48:31 μμ, Tobias wrote: Am 02.12.2011 16:22, schrieb Konstantinos Skarlatos: So, the transaction close is in btrfs_evict_inode, which sounds like a deadlock recently fixed by this commit: http://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=aa38a711a893accf5b5192f3d705a120deaa81e0 If you pull the for-linus branch from today, hopefully the problem will be gone. This looks very good. With this Kernel i still have some hangs, but only in rsync, only under high load and they don't lock up the system - so i guess it's ok now. I still have hangs and lock ups under the same situation (rsync of many files) under 3.2rc3. rc3 made the hang appear after 200gb of files, while in rc2 i had hangs after only 11gb . Yes, i had them too in 3.2rc3! The problem where solved with patches from the btrfs-for-linus -branch. (see link above). Tobias -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Blocked for more than 120 seconds
After about 1TB of rsyncs from multiple servers at the same time, plus some heavy filesystem loading, i believe that 3.2rc4 solves the problem for me. Now if only we had deduplication and an fsck tool :) On Παρασκευή, 2 Δεκέμβριος 2011 9:53:10 μμ, Konstantinos Skarlatos wrote: I see they got into 3.2rc4, so I am now compiling it. I will report back in a few hours On Παρασκευή, 2 Δεκέμβριος 2011 5:48:31 μμ, Tobias wrote: Am 02.12.2011 16:22, schrieb Konstantinos Skarlatos: So, the transaction close is in btrfs_evict_inode, which sounds like a deadlock recently fixed by this commit: http://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=aa38a711a893accf5b5192f3d705a120deaa81e0 If you pull the for-linus branch from today, hopefully the problem will be gone. This looks very good. With this Kernel i still have some hangs, but only in rsync, only under high load and they don't lock up the system - so i guess it's ok now. I still have hangs and lock ups under the same situation (rsync of many files) under 3.2rc3. rc3 made the hang appear after 200gb of files, while in rc2 i had hangs after only 11gb . Yes, i had them too in 3.2rc3! The problem where solved with patches from the btrfs-for-linus -branch. (see link above). Tobias -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Blocked for more than 120 seconds
On Thu, Dec 01, 2011 at 09:20:53AM +0100, Tobias wrote: Hi Chris Am 30.11.2011 15:10, schrieb Chris Mason: We see a bunch of procs stuck waiting to start a transaction, but we don't see why they are waiting. Could you please capture a sysrq-t during this? That will show us all the waiters everywhere. We're really looking for the one proc stuck in btrfs_commit_transaction, he's the key to the stalls. This is my first time working with sysrq... i hope i did it right... Here is the logoutput (quite much) So, the transaction close is in btrfs_evict_inode, which sounds like a deadlock recently fixed by this commit: http://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=aa38a711a893accf5b5192f3d705a120deaa81e0 If you pull the for-linus branch from today, hopefully the problem will be gone. -chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Blocked for more than 120 seconds
Am 28.11.2011 10:29, schrieb Chris Samuel: Hi Tobias, On Mon, 28 Nov 2011, 19:16:25 EST, Tobiastra...@robotech.de wrote: The problem occurs on the stock ubuntu kernel 2.6.38-8, 3.0.0-12, 3.0.0-13 and on my self-compiled 3.1.2. There's a lot of work gone into btrfs in 3.2, it would be interesting to know (speaking as just another user) whether it still occurs with 3.2-rc3. I tried 3.2-rc3 tonight but the messages are still there: [46203.412044] INFO: task rsync:1653 blocked for more than 120 seconds. [46203.412056] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [46203.412066] rsync D 8801d7d51aa0 0 1653 1647 0x [46203.412073] 8800042b1d98 0086 [46203.412079] 8801d7d516e0 8800042b1fd8 8800042b1fd8 8800042b1fd8 [46203.412084] 88023212db80 8801d7d516e0 0282 000122103228 [46203.412090] Call Trace: [46203.412101] [8161259f] schedule+0x3f/0x60 [46203.412126] [a01fd1bd] wait_current_trans.isra.22+0x9d/0x100 [btrfs] [46203.412132] [81085a40] ? add_wait_queue+0x60/0x60 [46203.412148] [a01fe7f5] start_transaction+0x135/0x2b0 [btrfs] [46203.412154] [8117bd5a] ? kern_path_create+0x8a/0x120 [46203.412171] [a01fec43] btrfs_start_transaction+0x13/0x20 [btrfs] [46203.412188] [a020a885] btrfs_link+0xa5/0x1a0 [btrfs] [46203.412193] [81178a91] vfs_link+0x101/0x190 [46203.412197] [8117ce88] sys_linkat+0x168/0x180 [46203.412200] [8117cebe] sys_link+0x1e/0x20 [46203.412205] [8161c442] system_call_fastpath+0x16/0x1b [46563.412042] INFO: task btrfs-delalloc-:31614 blocked for more than 120 seconds. [46563.412054] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [46563.412064] btrfs-delalloc- D 8801f8529aa0 0 31614 2 0x [46563.412071] 8801330bdc50 0046 0004 [46563.412077] 8801f85296e0 8801330bdfd8 8801330bdfd8 8801330bdfd8 [46563.412082] 88023212db80 8801f85296e0 0282 000122103228 [46563.412088] Call Trace: [46563.412098] [8161259f] schedule+0x3f/0x60 [46563.412124] [a01fd1bd] wait_current_trans.isra.22+0x9d/0x100 [btrfs] [46563.412130] [81085a40] ? add_wait_queue+0x60/0x60 [46563.412146] [a01fe8b0] start_transaction+0x1f0/0x2b0 [btrfs] [46563.412163] [a01fe9c5] btrfs_join_transaction+0x15/0x20 [btrfs] [46563.412179] [a0206423] compress_file_range+0x2d3/0x610 [btrfs] [46563.412197] [a0206795] async_cow_start+0x35/0x50 [btrfs] [46563.412213] [a02269ba] worker_loop+0x16a/0x560 [btrfs] [46563.412231] [a0226850] ? btrfs_queue_worker+0x300/0x300 [btrfs] [46563.412236] [81084fac] kthread+0x8c/0xa0 [46563.412241] [8161e5b4] kernel_thread_helper+0x4/0x10 [46563.412246] [81084f20] ? flush_kthread_worker+0xa0/0xa0 [46563.412250] [8161e5b0] ? gs_change+0x13/0x13 [46563.412255] INFO: task flush-btrfs-1:323 blocked for more than 120 seconds. [46563.412263] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [46563.412273] flush-btrfs-1 D 8802129bb180 0 323 2 0x [46563.412278] 8800209c58e0 0046 8800 8800218a2710 [46563.412284] 8802129badc0 8800209c5fd8 8800209c5fd8 8800209c5fd8 [46563.412290] 8802321444a0 8802129badc0 8800209c58e0 00018108f20d [46563.412295] Call Trace: [46563.412300] [8110dc90] ? __lock_page+0x70/0x70 [46563.412305] [8161259f] schedule+0x3f/0x60 [46563.412309] [8161264f] io_schedule+0x8f/0xd0 [46563.412313] [8110dc9e] sleep_on_page+0xe/0x20 [46563.412317] [81612d1a] __wait_on_bit_lock+0x5a/0xc0 [46563.412321] [8110dc87] __lock_page+0x67/0x70 [46563.412325] [81085a80] ? autoremove_wake_function+0x40/0x40 [46563.412342] [a021c945] extent_write_cache_pages.isra.21.constprop.31+0x215/0x3f0 [btrfs] [46563.412361] [a021cd65] extent_writepages+0x45/0x60 [btrfs] [46563.412378] [a0201350] ? acls_after_inode_item+0xc0/0xc0 [btrfs] [46563.412382] [81085614] ? bit_waitqueue+0x14/0xc0 [46563.412398] [a0200448] btrfs_writepages+0x28/0x30 [btrfs] [46563.412403] [811195f1] do_writepages+0x21/0x40 [46563.412409] [81194c70] writeback_single_inode+0x180/0x430 [46563.412413] [81195336] writeback_sb_inodes+0x1b6/0x270 [46563.412418] [8119548e] __writeback_inodes_wb+0x9e/0xd0 [46563.412422] [8119573b] wb_writeback+0x27b/0x330 [46563.412427] [81187352] ? get_nr_dirty_inodes+0x52/0x80 [46563.412432] [8119588f] wb_check_old_data_flush+0x9f/0xb0 [46563.412436] [81196731] wb_do_writeback+0x151/0x1d0 [46563.412441] [81611fd4] ?
Re: Blocked for more than 120 seconds
On Wed, Nov 30, 2011 at 10:44:15AM +0100, Tobias wrote: Am 28.11.2011 10:29, schrieb Chris Samuel: Hi Tobias, On Mon, 28 Nov 2011, 19:16:25 EST, Tobiastra...@robotech.de wrote: The problem occurs on the stock ubuntu kernel 2.6.38-8, 3.0.0-12, 3.0.0-13 and on my self-compiled 3.1.2. There's a lot of work gone into btrfs in 3.2, it would be interesting to know (speaking as just another user) whether it still occurs with 3.2-rc3. I tried 3.2-rc3 tonight but the messages are still there: We see a bunch of procs stuck waiting to start a transaction, but we don't see why they are waiting. Could you please capture a sysrq-t during this? That will show us all the waiters everywhere. We're really looking for the one proc stuck in btrfs_commit_transaction, he's the key to the stalls. -chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
