From: Daniel Dawson <danielcdawson@gmail.com>
To: Carlos Carvalho <carlos@fisica.ufpr.br>,
linux-ext4@vger.kernel.org, linux-raid@vger.kernel.org
Subject: Re: parity raid and ext4 get stuck in writes
Date: Sun, 24 Dec 2023 23:39:05 -0800 [thread overview]
Message-ID: <ed52f171-646f-47ff-ad3b-be8bef48d813@gmail.com> (raw)
In-Reply-To: <ZYX2AS8isUHtbMXe@fisica.ufpr.br>
On 12/22/23 12:48 PM, Carlos Carvalho wrote:
> This is finally a summary of a long standing problem. When lots of writes to
> many files are sent in a short time the kernel gets stuck and stops sending
> write requests to the disks. Sometimes it recovers and finally sends the
> modified pages to permanent storage, sometimes not and eventually other
> functions degrade and the machine crashes.
>
> A simple way to reproduce: expand a kernel source tree, like
> xzcat linux-6.5.tar.xz | tar x -f -
This sounds almost exactly like a problem I was having, right down to
triggering it by writing the files of a kernel tree, though the details
in my case are slightly different. I wanted to report it, but wanted to
get a better handle on it and never managed it, and now I've changed my
setup such that it doesn't happen anymore.
> - it happens only with ext4 on a parity raid array
This is where it differs for me. I experienced it only with btrfs. But I
had two arrays with it, one on SSDs and one on HDDs. The HDD array
exhibited the problem almost exclusively (the SSDs, I think, exhibited
it once in several months, while the HDDs did pretty much every time I
tried to compile a new kernel (until I started working around it), and
even from some other things, which was a couple of times a week). I
imagine because HDDs much slower and therefore allow more data to get
cached.
Now that I've switched the HDD array to ext4, I haven't experienced the
issue even once. But the setup has better performance, so maybe it's
just because it flushes its writes faster.
--
PGP fingerprint: 5BBD5080FEB0EF7F142F8173D572B791F7B4422A
next prev parent reply other threads:[~2023-12-25 7:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-22 20:48 parity raid and ext4 get stuck in writes Carlos Carvalho
2023-12-22 23:00 ` eyal
2023-12-25 7:39 ` Daniel Dawson [this message]
2023-12-25 10:15 ` Peter Grandi
2023-12-25 13:38 ` Carlos Carvalho
2024-01-04 6:11 ` Ojaswin Mujoo
2024-01-04 6:08 ` Ojaswin Mujoo
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=ed52f171-646f-47ff-ad3b-be8bef48d813@gmail.com \
--to=danielcdawson@gmail.com \
--cc=carlos@fisica.ufpr.br \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
/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