This post is also available in English and alternative languages.
我所使用的 NAS 为 QNAP TS-551 @ J3355，文件系统采用 EXT4，与 Btrfs 相比具有更好的吞吐量与访问延迟。
今日在对文件进行归档操作时，NAS 警告 “The server is busy or the network is disconnected”.
刷新页面后，提示 Connection reset，而在此期间文件可以通过 Samba 正常访问，通过 SSH 查看到 CPU 与 IO 的各项指标都正常，执行 dmesg 查看内核消息缓冲区，也未发现异常情况。通过 vi 查看各应用日志时，终端出现 write error in swap file 报错，但检查发现 swap 分区基本是空的，内存也空闲 10G 以上，不该出现此错误。
1
2
3
4
5
6
7
8
9
10
11
| [~] # uptime
21:28:37 up 26 min, load average: 5.32, 3.45, 2.81
[~] # iostat c
cpu
us sy wt id
28 13 4 54
[~] # free
total used free shared buffers cached
Mem: 10116140 4379452 5736688 289268 224628 2131248
-/+ buffers/cache: 2023576 8092564
Swap: 24542452 0 24542452
|
通过 CLI 执行 reboot 重启服务器后，访问 File Station 提示 System Message: network disconnected / Timeout。手动断开 HybridMount 中的云服务挂载后，在执行文件系统检查（基于 e2fsck）时发生错误 “Unmounting volume failed”。
通过报错信息查询到一篇帮助文档：Examination Failed(Cannot unmount disk) Error，通过 CLI 进行文件系统检查的指令顺序摘录如下：
1
2
3
4
5
6
7
8
9
10
| # 停止各项应用服务
/etc/init.d/services.sh stop
/etc/init.d/opentftp.sh stop
/etc/init.d/Qthttpd.sh stop
# 取消挂载并执行 fs 检查
umount /dev/mapper/cachedev1
e2fsck_64 -f -v -C 0 /dev/mapper/cachedev1
mount -t ext4 /dev/mapper/cachedev1 /share/CACHEDEV1_DATA
reboot
|
执行 umount 操作时，出现 error writing /etc/mtab.tmp: No space left on device 报错。由于存储池当前剩余空间超过 1TB，因此问题应该出现在系统挂载点上。使用 df 命令查看各挂载文件系统的使用状态，发现根目录使用率 100%。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| [admin@nonPointer ~]# df -h
Filesystem Size Used Available Use% Mounted on
none 400.0M 400.0M 0 100% /
devtmpfs 7.7G 8.0K 7.7G 0% /dev
tmpfs 64.0M 1.3M 62.7M 2% /tmp
tmpfs 7.8G 152.0K 7.8G 0% /dev/shm
tmpfs 16.0M 0 16.0M 0% /share
tmpfs 16.0M 0 16.0M 0% /mnt/snapshot/export
/dev/md9 493.5M 183.6M 309.9M 37% /mnt/HDA_ROOT
cgroup_root 7.8G 0 7.8G 0% /sys/fs/cgroup
/dev/mapper/cachedev1
6.8T 5.5T 1.3T 81% /share/CACHEDEV1_DATA
/dev/mapper/cachedev2
7.2T 2.2T 5.0T 30% /share/CACHEDEV2_DATA
/dev/mapper/cachedev3
98.7G 70.8M 98.1G 0% /share/CACHEDEV3_DATA
/dev/mapper/cachedev4
98.7G 60.3M 98.1G 0% /share/CACHEDEV4_DATA
...
|
参考 What do I do when my root filesystem is full?，使用 du 查看 / 下各目录的使用情况。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| [~] # sudo du -hsx /*
0 /1
4.4M /bin
8.0K /dev
6.8M /etc
0 /flashfs_tmp
0 /hd_root_tmp
85M /home
58M /lib
0 /lib64
0 /linuxrc
0 /lost+found
60K /mnt
0 /new_root
8.0K /opt
0 /php.ini
0 /proc
132M /PT
4.0K /qumagiecore.log
0 /QVS
48K /root
0 /rpc
0 /run
21M /sbin
16K /share
0 /sys
1.1M /tmp
93M /usr
2.1M /var
|
发现问题所在：名为 PT 的目录应该位于 /share/PT 路径，而不该出现在 /。查看后发现目录存放有部分今天通过 QBittorrent 移动的数据文件，应该是对 Qbittorrent 的文件进行分类存放时，目标路径填写了 /PT 而非 /share/PT，导致 rootfs 被填满。手动删除目录后重启系统，发现 /share/PT 路径依然存在，推测原因是没有从 Qbittorrent WebUI 移除对应种子。手动移除后再次重启系统，成功完成文件系统检查，未见系统异常。至此问题得到解决，通过此事也发现 QTS 的一项安全性隐患：所有 QNAP App 都以 admin（在 QTS 中相当于 root）的最高权限运行。在此也警告各位用户：谨慎安装由第三方分发的 QPKG 应用，把控好供应链安全。
