由XFS格式化并通过NFS共享的42TB LUN被客户报告为“不可用”。 最后，我被迫重新启动文件服务器。 XFS LUN在修复之前不会挂载，为了修复，我需要挂载它，这样日志才会重播并提交未提交的更改。 在过去，我了解到，转储日志并运行修复结果会导致LUN中文件和文件夹的部分文件名丢失。 42 TB和潜在的数十万个文件。 文件名的丢失等同于数据丢失。
我有一个备份。 恢复将需要收集资源。 我认为该LUN中大约有30TB的数据需要恢复并复制到原位。 所以我需要30 TB的可用空间，这是不容易获得的。
是否有另一种强制XFS挂载的方式来重放这些日志并提交更改？
这是我第三次对LUN进行“冻结”，并被报告为日志中的xfs损坏，并被迫重新启动服务器以使其恢复在线状态。 XFS似乎具有良好的声誉。 它已经存在了相当长的时间。 这是文件服务器操作系统（RHEL7）的默认设置。 我的configuration中是否有可怕的错误，导致这些LUN被破坏？
SAN在文件服务器上显示LUN，挂载nodev，nosuid，nofail。 将文件服务器共享到以共享方式安装共享的工作站。 在这个组合中是否会挂起文件服务器？