On 06.02.2019 01:22 Qu Wenruo wrote: > On 2019/2/6 上午6:18, Stephen R. van den Berg wrote: >> Are these Sysreq+w dumps not usable? >> > Sorry for the late reply. > > The hang looks pretty strange, and doesn't really look like previous > deadlock caused by tree block locking. > But some strange behavior about metadata dirty pages: > > This looks like to be the cause of the problem. > > kworker/u16:1 D 0 19178 2 0x80000000 > Workqueue: btrfs-endio-write btrfs_endio_write_helper > Call Trace: > ? __schedule+0x4db/0x524 > ? schedule+0x60/0x71 > ? schedule_timeout+0xb2/0xec > ? __next_timer_interrupt+0xae/0xae > ? io_schedule_timeout+0x1b/0x3d > ? balance_dirty_pages+0x7a7/0x861 > ? usleep_range+0x7e/0x7e > ? schedule+0x60/0x71 > ? schedule_timeout+0x32/0xec > ? balance_dirty_pages_ratelimited+0x204/0x225 > ? btrfs_finish_ordered_io+0x584/0x5ac > ? normal_work_helper+0xfe/0x243 > ? process_one_work+0x18d/0x271 > ? rescuer_thread+0x278/0x278 > ? worker_thread+0x194/0x23f > ? kthread+0xeb/0xf0 > ? kthread_associate_blkcg+0x86/0x86 > ? ret_from_fork+0x35/0x40 > > But I'm not familiar with balance_dirty_pages part, thus can't provide > much details about this. That balance_dirty_pages call was removed with the latest stable kernels ( https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/btrfs?h=linux-4.20.y&id=480c6fb23eb80e88eba7e4603304710ee7a9416f ).
