幸运的是，在尝试测量一些磁盘访问时间时，我发现 SSD 上有一个全零写入的文件包含一个非零字节。
我保留了该文件并对新文件进行了相同的试验，但找不到更多的非零字节。
然后我删除了所有文件并重新开始，结果再次在其中一个文件中发现非零字节。
然后我就跑了smartctl -t long。因为我读到它测试了整个“表面”，所以我认为对于 SSD 这意味着写入/读取每个字节并预期在某处提到的故障，但我找不到任何故障。
我认为最终它仍然可能是 RAM 错误，因为所有写入的字节都通过 RAM。
如果我想验证磁盘上是否存在该位而不是片状 RAM，我是否有机会以smartctl某种方式证明这一点？
答案1
我可以删除我的问题，但根据 @likkachu 在评论中的建议，下面的措辞方式就是答案。并警告其他人不要像我一样急于下结论，假设可能是磁盘。
那是个片状RAM正如评论中所建议的，运行内存测试仪很可能比试图证明 SSD 有故障更容易。我用了
- memtester（在 ubuntu 和其他发行版上可用）可以快速显示 RAM 存在问题。我无法用 memtester 找出它的物理地址。
- 由于 UEFI 启动，memtest86+ 很难启动，所以我曾经
dd将 memtest86 映像放在 USB 上并运行它。它给了我一个实际地址。但实际上最简单的是： - 添加参数 memtest（或 memtest=n，其中 n 在 [1..17] 中）作为内核引导参数，例如，通过编辑 grub 中的引导参数来进行单次引导（ESC 进入 EFI 的 grub，如果菜单通常会被跳过）。
内核发现了片状地址，请参阅/var/log/kern.log类似的内容
bad mem addr 0x00000000a31b7320 - 0x00000000a31b7328 reserved
然后我添加了
GRUB_BADRAM="0x0a31b7320,0xffffffff0"
就跑/etc/default/grub了update-grub。请注意，掩码有 9 位数字。对于 8 位数字，这将适用于每个 4GB RAM 块。
启动后，/var/log/kern.log包含
reserve setup_data: [mem 0x00000000a31b7000-0x00000000a31b7fff] unusable
这表明 grub 或内核将掩码四舍五入为 4096 字节的整页，这意味着掩码中过于具体也没有什么坏处GRUB_BADRAM。再次运行memtester，没有发现问题。