概述
在过去两年左右，我的台式计算机由于文件系统错误迫使 SSD 变为只读而间歇性崩溃。它可能会运行一个多星期而没有发生任何事情，并且可能在某一天崩溃不止一次。它似乎经常在备份和恢复期间的大量写入期间以及启动后立即触发，但也可能在其他时间发生。我曾经有一段时间认为我所做的事情解决了间歇性崩溃问题，但不久之后它又再次发生。
编辑：这些关闭通常会导致 UEFI 启动项损坏，从而需要多次电源循环才能启动。
我也会出现无法使用正确将文件复制到 USB 驱动器的情况$ dd，但按照如下所述修复我的 RAM 配置后，这个问题似乎已得到解决。
这种情况发生在不同发行版（全部基于 debian）和多个文件系统（ext4 和 btrfs）的多个安装中。
我的数据备份在外部驱动器上，最重要的部分通过同步存储在其他设备上。我认识到 SSD 随时都有可能失效。
规格配置
CPU：AMD 锐龙 9 3900x
固态硬盘：1 TB 三星 970 EVO Plus
RAM：Crucial Ballistix 3200 MHz (16GB x 2) BL2K16G32C16U4B
主板：华擎 B550 Phantom ITX
当前发行版：KDE Neon
我尝试过的事情
几个月前，我使用 memtester（在 Linux 下运行，未独立启动）测试了 RAM，并且我可能在一年前的某个时候对它进行了更广泛的测试。在我对此 RAM 进行的任何测试中，都没有出现任何内存错误。
我发现我的 RAM 显然需要默认 1.35V 的工厂超频电压。我在 BIOS 中修复了这个问题。这似乎有助于解决 USB 驱动器和 SD 卡的错误写入问题，但无法解决间歇性崩溃问题。我之前已经阅读并调整过其他设置，但目前一切似乎都设置为出厂默认值。
我大约一年前更新了 UEFI 固件。
我将 UEFI 固件更新到最新版本。
我尝试升级 SSD 上的固件，但似乎是特定版本支持的最新版本。
我已经调整了启动参数的 ASPM 设置，如上所述这有类似症状的问题。
我已经使用 smartmontools -> smartctl 检查了 SSD。似乎没有什么异常。
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART/Health Information (NVMe Log 0x02)
Critical Warning: 0x00
Temperature: 56 Celsius
Available Spare: 100%
Available Spare Threshold: 10%
Percentage Used: 0%
Data Units Read: 19,717,312 [10.0 TB]
Data Units Written: 39,276,405 [20.1 TB]
Host Read Commands: 117,854,095
Host Write Commands: 1,047,333,000
Controller Busy Time: 1,195
Power Cycles: 702
Power On Hours: 1,261
Unsafe Shutdowns: 30
Media and Data Integrity Errors: 0
Error Information Log Entries: 3,591
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0
Temperature Sensor 1: 56 Celsius
Temperature Sensor 2: 55 Celsius
journalctl | egrep 'kernel.*nvme'编辑：这些是在触发关闭和重新启动后立即在 dmesg 上输出的相关行$ stress-ng --hdd $(nproc)。
Jul 03 23:38:51 $HOSTNAME kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.13.0-51-generic root=UUID=e624d68e-7ffe-4bdb-98e3-a349ac9cc3e0 ro quiet splash nvme_core.default_ps_max_latency_us=0 pcie_aspm=off vt.handoff=7
Jul 03 23:38:51 $HOSTNAME kernel: Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.13.0-51-generic root=UUID=e624d68e-7ffe-4bdb-98e3-a349ac9cc3e0 ro quiet splash nvme_core.default_ps_max_latency_us=0 pcie_aspm=off vt.handoff=7
Jul 03 23:38:51 $HOSTNAME kernel: nvme nvme0: pci function 0000:01:00.0
Jul 03 23:38:51 $HOSTNAME kernel: nvme nvme0: missing or invalid SUBNQN field.
Jul 03 23:38:51 $HOSTNAME kernel: nvme nvme0: Shutdown timeout set to 8 seconds
Jul 03 23:38:51 $HOSTNAME kernel: nvme nvme0: 32/0/0 default/read/poll queues
Jul 03 23:38:51 $HOSTNAME kernel: nvme0n1: p1 p2 p3 p4 p5
Jul 03 23:38:51 $HOSTNAME kernel: EXT4-fs (nvme0n1p3): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
Jul 03 23:38:51 $HOSTNAME kernel: EXT4-fs (nvme0n1p3): re-mounted. Opts: (null). Quota mode: none.
Jul 03 23:38:51 $HOSTNAME kernel: Adding 67108860k swap on /dev/nvme0n1p2. Priority:-2 extents:1 across:67108860k SSFS
Jul 03 23:38:51 $HOSTNAME kernel: EXT4-fs (nvme0n1p4): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
Jul 03 23:38:52 $HOSTNAME kernel: EXT4-fs (nvme0n1p5): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
我的发现
我终于找到了总是导致崩溃发生的东西：
$ stress-ng --hdd $(nproc)
$ iotop -o显示由于磁盘被迫进入只读状态，所有 I/O 活动在 10 秒内停止，并且由于 systemd-journald 或其他无法写入磁盘而在 20 秒内发生关闭。
根据手动的对于stress-ng，正在写入、读取和删除临时文件。其他来源声称正在使用 write() 和 unlink() 调用。
其他选项例如
$ stress-ng --io $(nproc)
$ stress-ng --cpu $(nproc)
$ stress-ng --vm $(nproc)
$ stress-ng --iomix $(nproc)
似乎不会造成任何麻烦。
问题
压力测试$ stress-ng --hdd $(nproc)使我的计算机持续崩溃的独特能力是否一定意味着 SSD 硬件是罪魁祸首？
我读到，SSD 因发生灾难性故障而闻名，因此我不确定问题是否真的出在 SSD 上。我非常有兴趣更好地了解问题的本质，因此我非常感谢相关文档的链接或可以提供有关该主题的任何智慧之言。