我可以连续重现问题（并且只需几分钟），但我在日志中找不到任何有用的消息。该问题发生在 RocketRaid 3740C HBA 和专有 nvidia 驱动程序上，但现在发生在 LSI/Broadcom 9305-16i HBA 和 nouveau 驱动程序上。我已将 Broadcom 卡刷新到最新固件和 BIOS。主机总线适配器连接到 9 个驱动器（共 10 个，RAID 6 降级，直到替换磁盘到达）。网卡是 Mellanox ConnectX3，在光纤上运行 10G 以太网。在我更换 RocketRaid 卡之前，我记得看到专有驱动程序写入内核日志，说在崩溃前预期有 18 条消息，但实际却有 20 条消息。但我似乎再也找不到这些消息了（感谢您提供如何找到它们的指示！）。
重现步骤：
将大量内容写入磁盘（写入速度 > 700MB/s）。例如，从另一台计算机打开 3 个 scp 会话，并以 ~250MB/s 的速度并行写入 3 个文件。不到五分钟，Ubuntu 屏幕就冻结/锁定，ssh 无响应。硬重置似乎是唯一的选择。此后，mdadm 认为阵列已脏（即使所有驱动器上的事件计数相同）。mdadm assemble --force 有效，但阵列需要一天时间重新同步。
我对此已经束手无策了。我正在考虑看看 TrueNAS 或 Alma Linux 会发生什么。我也对主板 (ASRock Tachi X570) 有点好奇。系统似乎在任何不涉及大量写入阵列的负载下都表现良好，包括 CPU (5700x) 和密集的网络流量（我可以反复发送/接收 10 GB 的网络流量并获得 ~70 Gbit/s 的带宽）。
根据@heynnema 的评论进行编辑
$ sudo free -h
total used free shared buff/cache available
Mem: 62Gi 12Gi 442Mi 372Mi 50Gi 49Gi
Swap: 975Mi 44Mi 931Mi
sudo sysctl vm.swappiness
vm.swappiness = 60
phil@omni:~$ sudo dmidecode -s bios-version
P4.30
Tasks: 428 total, 2 running, 426 sleeping, 0 stopped, 0 zombie
%Cpu(s): 34.8 us, 2.0 sy, 0.0 ni, 61.1 id, 0.0 wa, 0.0 hi, 2.0 si, 0.0 st
MiB Mem : 64242.9 total, 1192.4 free, 14388.3 used, 48662.3 buff/cache
MiB Swap: 976.0 total, 915.5 free, 60.5 used. 48780.6 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
15919 fooo 20 0 4083880 3.6g 12520 S 312.5 5.7 77:36.68 chia
15560 fooo 20 0 4083904 3.6g 12544 S 93.8 5.7 77:43.99 chia
4764 root 20 0 0 0 0 S 18.8 0.0 93:17.25 md0_raid6
1375 unifi 20 0 4028748 180588 21888 S 6.2 0.3 0:04.47 launcher
2154 unifi 20 0 1078716 132904 39776 S 6.2 0.2 0:25.11 mongod
4776 root 20 0 0 0 0 R 6.2 0.0 18:39.73 md0_resync
15419 root 20 0 0 0 0 I 6.2 0.0 0:01.07 kworker/0:1-events
1 root 20 0 168296 11728 7896 S 0.0 0.0 0:01.02 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H-kblockd
9 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq
10 root 20 0 0 0 0 S 0.0 0.0 0:06.43 ksoftirqd/0
11 root 20 0 0 0 0 I 0.0 0.0 0:04.24 rcu_sched
12 root rt 0 0 0 0 S 0.0 0.0 0:00.02 migration/0
13 root -51 0 0 0 0 S 0.0 0.0 0:00.00 idle_inject/0
cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/vgubuntu-root / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=3C3E-4180 /boot/efi vfat umask=0077 0 1
/dev/mapper/vgubuntu-swap_1 none swap sw 0 0
#192.168.1.192:/storage /storage nfs defaults 0 0
UUID=ddc550d2-7f93-4ecf-ac2e-d754c5eee6c9 /storage xfs defaults 0 0
UUID=BCB65C49B65C05F4 /var/ExChia1 ntfs defaults 0 0
UUID=3A10-3FE7 /var/ExChia4 exfat defaults 0 0
UUID=0EF0-7586 /var/ExChia5 exfat defaults 0 0
UUID=3837-E26A /var/ExChia6 exfat defaults 0 0
UUID=73338b75-d356-4e7f-9757-948f1078f04e /var/ExChia13 xfs defaults 0 0
答案1
所以，我遇到了和你完全一样的问题。
通过 mdadm 设置 11 个磁盘软件 RAID6，带有 XFS 分区。磁盘通过主板 SATA 和 broadcom HBA SATA 端口组合连接。
在 Ubuntu 20.04.3 LTS 上，每当我在足够短的时间内进行足够高的带宽写入时，系统就会完全冻结。
为了排除任何其他设备或网络问题，我发现通过将 1TB 垃圾文件写入阵列 dd if=/dev/zero of=testfile bs=1024 count=1024000000 status=progress是重现该问题的最可靠方法。
解决方案是升级到 Ubuntu 21.10。Ubuntu 21.04 需要更长的时间才能冻结，但仍然会冻结。在 Ubuntu 21.10 上，我可以毫无问题地执行 3 次完整的 1TB 测试文件。导致此问题的任何错误最终都已修复。