From: Martin Raiber <martin@urbackup.org>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>,
"Stephen R. van den Berg" <srb@cuci.nl>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: New hang (Re: Kernel traces), sysreq+w output
Date: Wed, 6 Feb 2019 00:36:18 +0000 [thread overview]
Message-ID: <01020168c03beaab-004038b6-b18d-4b70-9803-4a9e51f73d36-000000@eu-west-1.amazonses.com> (raw)
In-Reply-To: <db1081bb-d8c4-0ad4-104f-e22d5acce3b4@gmx.com>
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
).
next prev parent reply other threads:[~2019-02-06 0:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-10 12:05 Kernel traces Stephen R. van den Berg
2018-12-10 16:54 ` Chris Murphy
2018-12-11 11:52 ` Stephen R. van den Berg
2018-12-12 6:16 ` Chris Murphy
2018-12-12 7:26 ` Stephen R. van den Berg
2018-12-12 21:01 ` Chris Murphy
2018-12-28 9:20 ` Stephen R. van den Berg
2018-12-28 10:10 ` Qu Wenruo
2018-12-28 13:40 ` Stephen R. van den Berg
2018-12-28 13:46 ` Qu Wenruo
2018-12-28 15:00 ` Stephen R. van den Berg
2019-01-23 15:50 ` Stephen R. van den Berg
2019-01-25 8:01 ` New hang (Re: Kernel traces), sysreq+w output Stephen R. van den Berg
2019-01-25 8:04 ` Stephen R. van den Berg
2019-02-05 22:18 ` Stephen R. van den Berg
2019-02-06 0:22 ` Qu Wenruo
2019-02-06 0:36 ` Martin Raiber [this message]
2019-07-26 16:31 ` qgroup: Don't trigger backref walk at delayed ref insert time (Re: Kernel traces) Stephen R. van den Berg
2019-07-26 23:24 ` Qu Wenruo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01020168c03beaab-004038b6-b18d-4b70-9803-4a9e51f73d36-000000@eu-west-1.amazonses.com \
--to=martin@urbackup.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=srb@cuci.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).