Hello, > # it is still not clear who is holding the lock Further analysis shows that the xfs_buf lock is being held, because the buffer is currently being read from disk. The stack that unlocks the buffer is [1]. The size of each buffer being read is 4Kb. So bottom line is that sometimes XFS needs to search through thousands of metadata blocks of 4Kb, and needs to wait while they are being read from disk. This causes very slow allocation in some cases, further causing other threads to wait on i_lock/i_mutex, in some cases triggering hung-task panics. Anything can be done to remedy this? Thanks, Alex. [1] Call Trace: [<ffffffff81710c85>] dump_stack+0x4e/0x71 [<ffffffffc0fade1b>] xfs_buf_ioend+0x22b/0x230 [xfs] [<ffffffffc0fade35>] xfs_buf_ioend_work+0x15/0x20 [xfs] [<ffffffff8108bd56>] process_one_work+0x146/0x410 [<ffffffff8108c141>] worker_thread+0x121/0x450 [<ffffffff8108c020>] ? process_one_work+0x410/0x410 [<ffffffff810911b9>] kthread+0xc9/0xe0 [<ffffffff810910f0>] ? kthread_create_on_node+0x180/0x180 [<ffffffff81717918>] ret_from_fork+0x58/0x90 [<ffffffff810910f0>] ? kthread_create_on_node+0x180/0x180 -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
