On Mon, 22 Jun 2026 00:32:19 -0700 David Christensen <[email protected]> wrote:
> I am glad that your storage is working correctly now. Thank you. > > > Please run and post the following commands with both the previous > kernel and the backports kernel: > > $ cat /etc/debian_version > > $ uname -a Backport root@hawk:~# cat /etc/debian_version 13.5 root@hawk:~# cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 13 (trixie)" NAME="Debian GNU/Linux" VERSION_ID="13" VERSION="13 (trixie)" VERSION_CODENAME=trixie DEBIAN_VERSION_FULL=13.5 ID=debian HOME_URL="https://www.debian.org/"; SUPPORT_URL="https://www.debian.org/support"; BUG_REPORT_URL="https://bugs.debian.org/"; root@hawk:~# uname -s Linux root@hawk:~# uname -a Linux hawk 7.0.10+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 7.0.10-1~bpo13+1 (2026-05-28) x86_64 GNU/Linux root@hawk:~# Prior kernel is the same except the kernel is linux-image-6.12.90+deb13.1-amd64 6.12.90-2 amd64 I think that this problem first showed up late April or early May. If that is correct, the following extracts from my apt logs might help. These were copied and pasted unwrapped, so unless they were mangled in transit, long lines should be preserved. Start-Date: 2026-04-13 12:46:25 Commandline: apt install -t trixie-backports linux-image-amd64 Install: linux-image-6.19.10+deb13-amd64:amd64 (6.19.10-1~bpo13+1, automatic), linux-modules-6.19.10+deb13-amd64:amd64 (6.19.10-1~bpo13+1, automatic), linux-base-amd64:amd64 (6.19.10-1~bpo13+1, automatic), linux-binary-6.19.10+deb13-amd64:amd64 (6.19.10-1~bpo13+1, automatic), linux-base-6.19.10+deb13-amd64:amd64 (6.19.10-1~bpo13+1, automatic) Upgrade: linux-image-amd64:amd64 (6.12.74-2, 6.19.10-1~bpo13+1), linux-libc-dev:amd64 (6.12.74-2, 6.19.10-1~bpo13+1) End-Date: 2026-04-13 12:46:52 Start-Date: 2026-04-16 08:45:37 Commandline: apt remove linux-image-amd64 Remove: linux-image-amd64:amd64 (6.19.10-1~bpo13+1) End-Date: 2026-04-16 08:45:39 Start-Date: 2026-04-16 08:45:47 Commandline: apt install linux-image-amd64 Install: linux-image-amd64:amd64 (6.12.74-2) End-Date: 2026-04-16 08:45:49 Start-Date: 2026-04-18 11:27:13 Commandline: apt install -t trixie-backports linux-image-amd64 Install: linux-image-6.19.11+deb13-amd64:amd64 (6.19.11-1~bpo13+1, automatic), linux-modules-6.19.11+deb13-amd64:amd64 (6.19.11-1~bpo13+1, automatic), linux-binary-6.19.11+deb13-amd64:amd64 (6.19.11-1~bpo13+1, automatic) Upgrade: linux-image-amd64:amd64 (6.12.74-2, 6.19.11-1~bpo13+1) End-Date: 2026-04-18 11:27:44 Start-Date: 2026-04-21 10:35:49 Commandline: apt purge linux-image-amd64 Purge: linux-image-amd64:amd64 (6.19.11-1~bpo13+1) End-Date: 2026-04-21 10:35:52 Start-Date: 2026-04-21 10:36:06 Commandline: apt install linux-image-amd64 Install: linux-image-amd64:amd64 (6.12.74-2) End-Date: 2026-04-21 10:36:08 Start-Date: 2026-05-01 04:40:22 Commandline: /usr/bin/unattended-upgrade Install: linux-image-6.12.85+deb13-amd64:amd64 (6.12.85-1, automatic) Upgrade: linux-image-amd64:amd64 (6.12.74-2, 6.12.85-1) End-Date: 2026-05-01 04:40:45 Start-Date: 2026-05-09 04:49:58 Commandline: /usr/bin/unattended-upgrade Install: linux-image-6.12.86+deb13-amd64:amd64 (6.12.86-1, automatic) Start-Date: 2026-05-16 04:01:47 Commandline: /usr/bin/unattended-upgrade Install: linux-image-6.12.88+deb13-amd64:amd64 (6.12.88-1, automatic) Start-Date: 2026-05-24 11:54:07 Commandline: /usr/bin/unattended-upgrade Install: linux-image-6.12.90+deb13-amd64:amd64 (6.12.90-1, automatic) Start-Date: 2026-05-29 04:08:32 Commandline: /usr/bin/unattended-upgrade Install: linux-image-6.12.90+deb13.1-amd64:amd64 (6.12.90-2, automatic) Start-Date: 2026-06-20 11:19:40 Commandline: apt install -t trixie-backports linux-image-amd64 Apparently, twice in April I had tried the backports kernel(s), and found them unsatisfactory. So possibly the fix came in between linux-image-6.19.11+deb13-amd64 and the current backports kernel, linux-image-7.0.10+deb13-amd64. Quite possibly a major version number might even inadvertently fix something as subtle as this. > > > I will assume your script spawns a separate, isolated process for > each checksum file. Correct. It does a find on *.sha256sums, *.sha512sums, and several other suffixes. It then sliced and dices to figure out the appropriate program to call, sha256sum and sha512sum, respectively. The files are created using paths relative to the current directory, so when the script runs, it will pushd to that directory The key line is nice "${prog}" "${opts}" -c "${file}" & Where $prog is the result of the slicing and dicing, opts='--quiet', and $file the file to be scanned. I recently added the option to limit the number of background tasks to the number of processors (nproc --all). That reduces but does not eliminate the number of errors. > > > If you have ruled out the power supply, memory, and disks, another > possibility could be a race condition in the kernel and/or I/O stack > that is triggered when multiple processes access storage in parallel. I wouldn't say those are all ruled out. But the fact that the backport kernel is a major version number change, and that it appears to have solved the problem is highly suggestive. With that caveat, I concur. That is definitely something for the kernel folks to look at. > > > Are the checksum errors repeatable on another computer with a similar > storage architecture and the previous kernel? If so, do they > disappear with the backports kernel? I have a much more recent and much faster computer, peregrine, with nvme storage and 12 cores. Hawk has eight cores, and spinning rust. Hawk is where the problem has shown up. Peregrine does not show the problem. For 18 gig of data, hawk: 2m18.318s, peregrine 0m24.233s. > > > David -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
