Re: problem with recovered array

[Carlos Carvalho <carlos@fisica.ufpr.br>]

Johannes Truschnigg (johannes@truschnigg.info) wrote on Thu, Nov 02, 2023 at 05:34:51AM -03:
> for the record, I do not think that any of the observations the OP made can be
> explained by non-pathological phenomena/patterns of behavior. Something is
> very clearly wrong with how this system behaves (the reported figures do not
> at all match the expected performance of even a degraded RAID6 array in my
> experience) and how data written to the filesystem apparently fails to make it
> into the backing devices in acceptable time.
> 
> The whole affair reeks either of "subtle kernel bug", or maybe "subtle
> hardware failure", I think.

Exactly. That's what I've been saying for months...

I found a clear comparison: expanding the kernel tarball in the SAME MACHINE
with 6.1.61 and 6.5.10. The raid6 array is working normally in both cases. With
6.1.61 the expansion works fine, finishes with ~100MB of dirty pages and these
are quickly sent to permanent storage. With 6.5.* it finishes with ~1.5GB of
dirty pages that are never sent to disk (I waited ~3h). The disks are idle, as
shown by sar, and the kworker/flushd runs with 100% cpu usage forever.

Limiting the dirty*bytes in /proc/sys/vm the dirty pages stay low BUT tar is
blocked in D state and the tarball expansion proceeds so slowly that it'd take
days to complete (checked with quota).

So 6.5 (and 6.4) are unusable in this case. In another machine, which does
hundreds of rsync downloads every day, the same problem exists and I also get
frequent random rsync timeouts.

This is all with raid6 and ext4. One of the machines has a journal disk in the
raid and the filesystem is mounted with nobarriers. Both show the same
behavior. It'd be interesting to try a different filesystem but these are
production machines with many disks and I cannot create another big array to
transfer the contents.