月度归档： 2014年8月

8月31日 16:40，freeshell 3 号物理节点重新启动，现在服务已经恢复正常。

问题源于一个 freeshell 内的两个进程在退出过程中，mmap 加载的 exe 文件在关闭时，NFS 的 CTO（close to open）功能为保证缓存一致性，会发起 NFS 请求来检查该缓存的文件项是否过期了。如果此操作被卡住，则该进程就成了不可中断状态的僵尸进程，如下所示。

root      893850  0.0  0.0      0     0 ?        D    Aug30   0:00 [ifup]
root      893903  0.0  0.0      0     0 ?        D    Aug30   0:00 [sleep]

尽管 RPC wait 使用的是 killable，但在退出过程中的进程已经变成 uninterruptible，因此 SIGKILL 信号是不起作用的。当然可以编写内核模块，把进程状态强制改成 Ready，这样 CPU 再次调度到此进程时就会走完退出流程，但我现在没有该版本内核的编译环境。简单起见，决定白天物理重启该服务器。

内核 stack trace（两个导致问题的进程相同）

[<ffffffffa04f69b4>] rpc_wait_bit_killable+0x24/0x40 [sunrpc]
[<ffffffffa04f698d>] __rpc_wait_for_completion_task+0x2d/0x30 [sunrpc]
[<ffffffffa05b64d3>] nfs4_do_close+0x203/0x270 [nfs]
[<ffffffffa05c4565>] __nfs4_close+0xc5/0x180 [nfs]
[<ffffffffa05c4638>] nfs4_close_sync+0x18/0x20 [nfs]
[<ffffffffa05b1320>] nfs4_close_context+0x30/0x40 [nfs]
[<ffffffffa0594d33>] __put_nfs_open_context+0xb3/0x110 [nfs]
[<ffffffffa0594e45>] nfs_release+0xb5/0xd0 [nfs]
[<ffffffffa0592b31>] nfs_file_release+0x61/0x90 [nfs]
[<ffffffff811ae468>] __fput+0xf8/0x280
[<ffffffff811ae615>] fput+0x25/0x30
[<ffffffff8121d289>] removed_exe_file_vma+0x39/0x50
[<ffffffff81170978>] remove_vma+0x118/0x130
[<ffffffff81170a68>] exit_mmap+0xd8/0x190
[<ffffffff8107305c>] mmput+0x5c/0x1f0
[<ffffffff81079a09>] exit_mm+0x109/0x150
[<ffffffff8107b7d7>] do_exit+0x187/0x930
[<ffffffff8107bfd8>] do_group_exit+0x58/0xd0
[<ffffffff8107c067>] sys_exit_group+0x17/0x20
[<ffffffff8100b102>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff

为避免此问题再次出现，考虑到 freeshell 外部存储的实际情况，现已关闭 CTO（close to open）功能。

昨晚 freeshell 外部存储上线以来，外部存储系统中的一些 UID 变成了 root（0）或 nobody（65534），导致一些文件权限问题。

经查，这是由于 NFSv4 协议并不是直接传输 UID/GID，而是在 NFS client 端由 idmap 服务将 UID/GID 转换成 [email protected] 的形式，以字符串形式传输给 NFS server，server 端的 idmap 服务再把字符串转换成 UID/GID。也就是说，client 与 server 的主机系统中只要至少有一端的 /etc/passwd 中不存在这个 UID/GID，就会出现问题。如果是从其他 freeshell 复制过来的，复制（rsync）过程中文件首先以 root 身份创建，随后的 chown 操作失败，所以 UID 就是 0；如果是在外部存储的 freeshell 中以“不存在”的用户身份创建文件，该文件的 UID 就会被 squash 成 nobody（65534）。

NFSv3 协议使用了数字 UID/GID 传输，不依赖 idmap 服务，不仅解决了 UID/GID 问题，还减少了无谓的开销。此问题现已解决。如果您今天新建或迁移了 freeshell，请自行修复 UID/GID，因此带来的不便望能谅解。

感谢 vanabel 的 bug 报告。

控制面板会显示 “Cannot connect to worker node”。这是由于内核里的 NFS 模块卡死了，我们正在调查这个问题。杀掉出问题的进程后已经恢复。非常抱歉此问题给您带来的影响。

由于 freeshell 硬盘空间告急，现把原来用作备份的 2T 7200rpm SATA 盘用作存储。新注册的 freeshell 和 Copy、Move后的 freeshell 都将使用新硬盘作为存储。现有 freeshell 的存储位置不变，重装系统和 Move 也不会改变存储位置。

新硬盘安装在 1 号节点上，其他节点使用 NFS 挂载。NFS 的小文件读写性能不是很好，但通过调整参数，达到了可以接受的性能。各节点连接同一个交换机，目前 MTU 为 9000，NFS server 挂载参数为 rw,async,no_subtree_check,no_root_squash，NFS client 挂载参数为 rw,rsize=32768,wsize=32768,udp,timeo=15,intr vers=3,rw,rsize=32768,wsize=32768,tcp,timeo=10,retrans=5,soft,intr,sec=sys,lookupcache=all,ac,nocto。

新参数主要做了如下优化，使得 NFS 的 I/O 性能与本地接近：

1. 使用 NFSv3 取代 NFSv4 协议，这样就不需要在 client 端把 UID/GID 转换成 [email protected]，在 server 端再转换回 UID/GID 了。
2. 由于不同节点始终在访问不同的数据，关闭文件时不需要刷新缓存，即 nocto 选项。这也修复了进程退出时关闭打开的文件需要刷新缓存导致的进程卡死问题。
3. 为避免 NFS 抽风导致应用挂死，使用 soft 选项，即查询失败时返回文件打开失败，而不是让应用程序挂起等待。使用 TCP 和更多的重传次数来提高稳定性。

初步测试结果（对比 2 号节点与 1 号节点上对 SATA 盘上 freeshell 的操作）：

• 解压 Debian wheezy minimal 系统 tar.gz 包：本地 6.925s，NFS 26.453s（NFS 比本地慢 3 倍） 本地 7.277s，NFS 19.897s（NFS 比本地慢 173%）
• 启动虚拟机，apt-get update，生成 locale：本地 10.674s，NFS 11.458s（NFS 比本地慢 7%） 本地 11.480s，NFS 10.790s（NFS 比本地快 6%）
• 安装 vim：本地 13.920s，NFS 16.911s（NFS 比本地慢 21%） 本地 8.911s，NFS 10.879s（NFS 比本地慢 22%）
• 安装 build-essential：本地 51.163s，NFS 77.057s（NFS 比本地慢 50%） 本地 52.708s，NFS 50.480s（NFS 比本地快 4%）

fio 磁盘性能测试结果（老参数的，新参数的未测试）：

新硬盘是 SATA 盘，性能本来就不如 SAS，再加上 NFS 和多台机器共享使用，性能可能会更差，因此仅作为磁盘空间不足时的救急方案。

如果您发现新注册的 freeshell 卡死，或者注册、复制、移动等操作长时间不能完成，请联系我们：support AT freeshell.ustc.edu.cn。

由于一些历史遗留问题，部分不存在的 freeshell 的端口映射仍然像幽灵一样存在于 ssh.freeshell.ustc.edu.cn 的 iptables 配置中，导致这些端口在控制面板中无法被映射。

为保证以后不再出现类似问题，现在不再使用 iptables 的增量更新功能，而是在每次端口映射配置发生变化时，生成完整的 iptables 配置文件，再用 iptables-restore 安装上去。非常抱歉端口映射不一致问题可能给您带来的麻烦。

感谢 Zitian Li 的 bug 报告。