Re: extremely slow writes to array [now not degraded]

eyal
2023-11-13T10:32:05Z

On 13/11/2023 21.09, Johannes Truschnigg wrote:
> On Mon, Nov 13, 2023 at 08:58:55PM +1100, eyal@eyal.emu.id.au 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.