客户报告称，42TB LUN（采用 XFS 格式并通过 NFS 共享）“不可用”。最后，我被迫重新启动文件服务器。XFS LUN 直到修复后才会挂载，而要修复，我需要挂载它，以便日志重播并提交未提交的更改。过去，我了解到转储日志并运行修复会导致 LUN 中部分文件和文件夹的文件名丢失。42 TB 和可能数十万个文件。文件名丢失等同于数据丢失。
我有一个备份。恢复需要收集资源。我认为该 LUN 中大约有 30 TB 的数据需要恢复并复制回原位。所以我需要 30 TB 的可用空间，但这并不容易获得。
是否有其他方法可以强制安装 XFS 以重播这些日志并提交更改？
这是我第三次遇到 LUN “冻结”的情况，并在日志中报告为 xfs 损坏，并被迫重新启动服务器以使其重新上线。XFS 似乎享有良好的声誉。它已经存在了相当长一段时间。它是文件服务器操作系统 (RHEL7) 的默认设置。我的配置中是否存在一些严重的错误，导致这些 LUN 被杀死？
SAN 提供 LUN、已安装的 nodev、nosuid、nofail 到文件服务器上。文件服务器共享到以同步方式安装共享的工作站。此组合中是否存在会导致文件服务器挂起的因素？
答案1
在检查错误更新时遇到了这个问题#1681410和#1686687在启动板上，我也受到了与您描述的类似症状的影响（也使用 XFS，但 LUN 更大，并且运行 ubuntu 16.04 服务器时）。
我们对存储系统（提供大量日志）进行了深入检查（请求制造商的支持），但最终没有发现任何错误或错误配置。
遇到这种情况几次后，我们设法将这种行为的发生时间确定为某个时间，此时可能没有人积极操作系统，这让我们也可以查看其他因素。我们最终发现证据表明，每周启动一次的 cron 计划运行 fstrim（这是 ubtuntu 16.04 服务器上的默认设置！）似乎会触发文件系统损坏，尤其是因为 fstrim 超过 100TB 大小的 LUN 需要一些时间。
我认为 launchpad 上发布的错误很可能描述了这个问题，但在我看来，这个问题已经被上传到上游，但迄今为止从未真正修复过。所以现在我们只需通过删除 cron.weekly 中的相应条目来确保没有运行 fstrim。我们还检查在运行更新后是否重新添加了 cron-job，我希望以不同的方式解决这个问题。