From: Manuel Riel <manu@snapdragon.cc>
To: Vojtech Myslivec <vojtech@xmyslivec.cz>
Cc: Chris Murphy <lists@colorremedies.com>,
Michal Moravec <michal.moravec@logicworks.cz>,
Linux-RAID <linux-raid@vger.kernel.org>,
songliubraving@fb.com, guoqing.jiang@cloud.ionos.com
Subject: Re: Linux RAID with btrfs stuck and consume 100 % CPU
Date: Sun, 28 Feb 2021 16:34:57 +0800 [thread overview]
Message-ID: <D3026A55-A7F2-4432-87A8-3E9B2CACE4C2@snapdragon.cc> (raw)
In-Reply-To: <DBB07C8C-0D83-47DC-9B91-78AD385775E3@snapdragon.cc>
Hit another mdadm "hanger" today. No more reading possible and md4_raid6 stuck at 100% CPU.
I've now moved the write journal off the RAID1 device. So it's not a "nested" RAID any more. Hope this will help.
With only one hardware device used as write cache, I suppose only write-through mode[1] is suggested now.
1: https://www.kernel.org/doc/Documentation/md/raid5-cache.txt
> On Feb 11, 2021, at 11:14, Manuel Riel <manu@snapdragon.cc> wrote:
>
> I'm also hitting the exact same problem with XFS on RAID6 using a RAID1
> write journal on two NVMes. CentOS 8, 4.18.0-240.10.1.el8_3.x86_64.
>
> Symptoms:
>
> - high CPU usage of md4_raid6 process
> - IO wait goes up
> - IO on that file system locks up for tens of minutes and the kernel reports:
>
> [Wed Feb 10 23:23:05 2021] INFO: task md4_reclaim:1070 blocked for more than 20 seconds.
> [Wed Feb 10 23:23:05 2021] Not tainted 4.18.0-240.10.1.el8_3.x86_64 #1
> [Wed Feb 10 23:23:05 2021] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [Wed Feb 10 23:23:05 2021] md4_reclaim D 0 1070 2 0x80004000
>
> Already confirmed it's not a timeout mismatch. No drive errors reported. SCT Error Recovery
> Control is set to 7 seconds
next prev parent reply other threads:[~2021-02-28 8:36 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-22 20:47 Linux RAID with btrfs stuck and consume 100 % CPU Vojtech Myslivec
2020-07-22 22:00 ` antlists
2020-07-23 2:08 ` Chris Murphy
[not found] ` <29509e08-e373-b352-d696-fcb9f507a545@xmyslivec.cz>
2020-07-28 20:23 ` Chris Murphy
[not found] ` <695936b4-67a2-c862-9cb6-5545b4ab3c42@xmyslivec.cz>
2020-08-14 20:04 ` Chris Murphy
[not found] ` <2f2f1c21-c81b-55aa-6f77-e2d3f32d32cb@xmyslivec.cz>
2020-08-19 22:58 ` Chris Murphy
2020-08-26 15:35 ` Vojtech Myslivec
2020-08-26 18:07 ` Chris Murphy
2020-09-16 9:42 ` Vojtech Myslivec
2020-09-17 17:08 ` Chris Murphy
2020-09-17 17:20 ` Chris Murphy
2020-09-17 17:43 ` Chris Murphy
2020-09-23 18:14 ` Vojtech Myslivec
2021-02-11 3:14 ` Manuel Riel
2021-02-28 8:34 ` Manuel Riel [this message]
[not found] ` <56AD80D0-6853-4E3A-A94C-AD1477D3FDA4@snapdragon.cc>
2021-03-17 15:55 ` Vojtech Myslivec
2020-07-29 21:06 ` Guoqing Jiang
2020-07-29 21:48 ` Chris Murphy
2020-08-12 14:19 ` Vojtech Myslivec
2020-08-12 14:19 ` Vojtech Myslivec
2020-07-30 6:45 ` Song Liu
2020-08-12 13:58 ` Vojtech Myslivec
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=D3026A55-A7F2-4432-87A8-3E9B2CACE4C2@snapdragon.cc \
--to=manu@snapdragon.cc \
--cc=guoqing.jiang@cloud.ionos.com \
--cc=linux-raid@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=michal.moravec@logicworks.cz \
--cc=songliubraving@fb.com \
--cc=vojtech@xmyslivec.cz \
/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).