起因

在8月初的时候，我接下了学校信息学院某实验室集群助管的工作，上任第一天的工作就是配置管理环境。集群的架构大致是这样，一共是约30台服务器，在上面跑 docker , 映射 ssh 端口，分派给不同的用户使用。除此以外还有两台大容量NFS服务器用于用户存储数据。

我使用了 Portainer.io 进行多机器的 docker 管理。同时用了一个 shell 来完成其它机器运行 portainer.io - agent 以及挂载 nfs 磁盘的操作。

脚本

ERROR

在某一次，由于 NFS 磁盘掉线导致 docker 卡在了 create 的状态上。没有在意，在 nfs 服务器重新上线后重启服务器，发现 docker 掉线了。不过机器足够多，因此把原先的 docker 放在了新的机器上面，这台服务器的问题就被搁置了。

昨天去 SHLUG 的时候见到了 @LightQuantum ，顺便和他说起了这件事情。我们都觉得很奇怪，于是进行排查，发现整个文件系统都被写保护了。最后发现在 /etc/fstab 中是这么写的

10.15.??.??:/mnt/data /mount nfs  0 0
10.15.??.??:/mnt/data /mount1 nfs  0 0

于是想起来脚本中的这一行

echo 'helloworld' > aaaa

只有一个 ‘>’ 是覆盖文件并写入，因此我抹掉了整个分区表。

还好大部分服务都在内存中，修复起来稍微容易一些。除了之前被重启过的和为了试验当场重启的。

于是后面两台服务器，首先挂载分区

 mount -o remount,rw /dev/sda3 /

对于其它机器以及这两台服务器，更改其分区文件

/dev/sda3 / ext4 defaults,relatime 0 1
/dev/sda1 /boot ext4 defaults,relatime 0 0
/dev/sda2 none swap defaults 0 0
/dev/sdb1 /data ext4 defaults,relatime 0 0
10.15.??.??:/mnt/data /mount nfs defaults 0 0
10.15.??.??:/mnt/data /mount1 nfs defaults 0 0

加入 defaults 属性也许会让 nfs 运行的更好一些。

这样就修复完成了。