我在 Ubuntu 20.04 系统中添加了一个全新的驱动器，进行了所有设置，将其格式化为 XFS，现在两天内系统崩溃了两次，控制台上出现以下错误：
XFS (sdb1): Log I/O Error Detected. Shutting down filesystem
XFS (sdb1): Please unmount the filesystem and rectify the problem(s)
不幸的是，日志中没有任何内容能让我得出问题可能出在哪里的结论。以下是 dmesg 中的内容：
[ 295.495988] XFS (sdb1): Metadata CRC error detected at xfs_inobt_read_verify+0x1a/0xc0 [xfs], xfs_inobt block 0x30
[ 295.498465] XFS (sdb1): Unmount and run xfs_repair
[ 295.515359] XFS (sdb1): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x30 len 8 error 74
[ 295.517401] XFS (sdb1): xfs_do_force_shutdown(0x1) called from line 325 of file fs/xfs/xfs_trans_buf.c. Return address = 0000000099c0d7d2
当然，尝试搜索错误几乎无济于事，而且问题已经出现了好几次。幸运的是，这是不是生产系统然而！我检查了所有电缆，拔出并重新安装驱动器，重新启动系统，甚至还对驱动器进行了大约 10TB 的 dd 操作。然后它又发生了。我不知道我看到的是坏电缆、坏硬盘（智能显示驱动器没有问题）、坏 SAS 控制器，还是其他什么
我根本找不到针对此错误的任何好的故障排除方法，因此我希望这里有人见过同样的事情并能帮助我。
谢谢
答案1
或者，跳到最后查看惊喜解决方案。这通常发生在磁盘接近 90% 满时。目前还没有解决方案，除了将数据传输到其他驱动器，并且不要让 xfs 系统超过 85%。
当 xfs 日志包含未提交的数据时，可能会出现此问题，应通过卸载并重新挂载来解决。但如果没有，则需要sync在成功挂载后从命令行运行。
同步尝试提交缓存缓冲区，其中一些必须在 xfs 日志中完成（xfs、ext4 和其他是日志文件系统，它们将元数据缓存到与文件系统位于同一卷内的日志中，或缓存到不同文件系统中的单独日志文件中。）
但sync会导致同样的问题，即 xfs 文件系统关闭，块设备（即 /dev/sdc）消失，以防止文件系统损坏。
一种快速而粗略的方法是使用xfs_repair -L device未挂载文件系统。这将使日志清零。在重新创建设备节点、挂载文件系统（可能需要一段时间）、卸载文件系统，然后将日志清零后，应该就可以安全了。
如果您使用的是 SSD，则必须在将日志清零后修剪驱动器，否则行为可能会重复。目前，我正尝试将 xfs 日志移动到单独的文件中，并将其设置为 1TB NVMe USB 驱动器的 200GB 左右，协调缓存缓冲区，修剪 xfs 驱动器，然后将日志放回 1TB xfs 卷中。
但数据是本地 Debian amd64 镜像，因此可以重建。如果是不可替代的数据，我会挂载它，在文件系统关闭之前使用 rsync 移动尽可能多的数据，然后在sync不挂载 xfs 卷的情况下确保所有数据都已写入，然后再次挂载 xfs 卷，并删除我能够传输到其他存储的所有内容。
如果您可以将 15-20% 的驱动器空间分配给 xfs 系统，那么您应该能够提交缓存缓冲区并将sync所有内容清零。但我仍然会将xfs_repair -L device日志清零。
为了解决这个问题，我格式化了 USB 驱动器，并重建了 Debian 镜像。我有另一个相同的机箱，但没想到，它启动时的行为和装有 Debian 镜像的机箱一样不稳定。
不可能是巧合。不，不是。两个相同的 USB 外壳，2 个 1TB NVMe 驱动器，唯一的共同点是 USB 电缆。我换了电缆，问题就解决了！
这么多那我生命中的 6 个小时！但我确实学会了如何制作单独的日志分区，这似乎是更好的方法。所以这不是完全浪费。
帖子的剩余部分是可靠的材料，减去 200GB 日志大小，对于 1TB 驱动器来说，这可能需要 20-30MB。我将日志分区设置为驱动器上最后一个扇区前 20MB 结束，因为我相信如果外部日志中的扇区出现问题，xfs 会分配该可用空间。