背景

操作系统传统上假定存储组件要么正常工作，要么已经损坏需要更换。大多数代码都是使用同步I/O模型开发的，其中操作会等待直到它们接收到成功的结果或错误。这种模型不适合涉及许多设备，尤其是网络（失败更为常见，可能是一时的）的复杂存储环境。此外，Linux、FreeBSD和macOS都存在严重的NFS客户端错误和设计缺陷，这显著放大了瞬间失败或过载造成的损害。

不幸的是，许多程序都有非明显的触发器，导致它们扫描所有挂载的文件系统，一旦任何挂载的文件系统停止响应，它们就会挂起。在NFS主目录的情况下，用户体验特别糟糕，因为大多数桌面环境在尝试从用户的家目录访问配置文件时会完全挂起，使系统无法使用。

最后，很少有应用程序拥有报告存储请求长时间阻塞所需的复杂代码，这使得系统管理员难以主动解决问题。在某些情况下可能需要重启，但在许多情况下，通过使用umount -f或在Linux的某些情况下umount -f -l，重新挂载文件系统，可以显著减少临时中断的影响。

mount_status_monitor的功能

mount_status_monitor为不完美的存储提供了缺失的通知解决方案。它是一个简单的守护进程，定期使用带超时的异步检查检查每个挂载的文件系统，从而可以报告由无响应的存储引起的软错误以及硬错误。

每次运行完成后，它将向syslog发送消息

Checked 5 mounts; 0 are dead

可选地，Prometheus 推送网关将接收两个指标（total_mountpoints和dead_mountpoints），用于警报和关联目的，并具有相同的信息。

当挂载测试失败时，挂载点将被发送到syslog和stderr

Mount failed health-check: /Volumes/TestSSHFS

有几种方法可以模拟故障进行测试。最简单的方法是使用用户模式文件系统，例如sshfs、s3fs等，并使用kill -STOP来冻结FUSE进程足够长的时间，以触发无响应的挂载故障。对于更复杂的测试或如果您正在评估系统调整选项，可以使用iptables来模拟数据包丢失或NFS服务器的硬故障。

安装

编译代码需要一个工作的Rust工具链

cargo build --release

提供了一个Docker镜像以测试基本功能

docker build -t mountstatus . && docker run -it --rm mountstatus

运行监控器

对于测试，您可以直接运行mount_status_monitor并查看输出。请注意，虽然进程可以在没有提升权限的情况下运行，但它很可能会因为无法访问的挂载点而产生错误消息。

在正常操作中，mount_status_monitor依赖于诸如Upstart、systemd或launchd之类的管理器来保持其运行。请参阅提供的upstart和systemd目录中的配置文件。

未来方向

一个长期实验是让mount_status_monitor实际尝试运行umount -f（或在Linux上运行umount -f -l）并重新挂载文件系统，以减少遇到死挂载点的应用程序数量。这可能不适合所有用户，并且需要测试以避免使问题变得更糟。

贡献者 & 致谢

感谢以下自愿审查和改进此代码的Rust社区成员，按字母顺序排列

• Pascal Hertleif (@killercup)
• Paul Daniel Faria (@Nashenas88)
• Rahul Sharma (@creativcoder)
• Zachary Dremann (@Dr-Emann)