On 13/11/2023 21.09, Johannes Truschnigg wrote:
On Mon, Nov 13, 2023 at 08:58:55PM +1100, eyal@xxxxxxxxxxxxxx wrote:
[trimmed]
[0]: https://bugzilla.kernel.org/show_bug.cgi?id=217965
Reading this bugzilla, an extra info bit. This has not changed for years (I have daily records).
$ mount|grep data1
/dev/md127 on /data1 type ext4 (rw,noatime,stripe=640)
Yeah, afaiui, one of the theories in the bug suggests that a recently
introduced block allocation improvement made matters worse for any kind of
stride/stripe setting <> 0. So if you dial your kernel version back to before
that was made (6.4 seems to be unaffacted, iirc), you will probably regain the
performance loss you observe and reported here on list.
FWIW, I briefly played around with an artificial dataset on tmpfs-backed loop
devices configured in RAID5 where I was (re)setting the superblock-configured
stride-setting, and did not lose any data by toggling it between 0 and
<some_other_value> (256 in my case) multiple times. So I would assume that to
be a safe operation in principle ;)
I hear you but I am not brave enough :-(
I will avoid these huge copies and live with this problem(*1), expecting this will be fixed in a few weeks.
maybe even in 3.7? I will follow the bugzilla.
Still Thanks, I now feel that there is hope.
(*1) Most of the time this issue does not bite, and I may have had it for some time until I
took a closer look while dealing with a few raid disk replacements and noticed.
--
Eyal at Home (eyal@xxxxxxxxxxxxxx)
