磁盘

报 no space left on device，看上去是磁盘空间不足，但有可能不是存储满了，而是 inode 满了。用 df -i 查看 inode 使用情况，如果有 100% 的就是 inode 满了。 现象 报 no space left on device，看上去是磁盘空间不足了，那么找没用的文件删了即可。 但有可能不是存储满了，而是 inode 满了。 排查 使用 df -i 查看 inode 的使用情况，如果有 100% 的，那就说明是 inode 满了： root@host:~# df -i Filesystem Inodes IUsed IFree IUse% Mounted on udev 16059428 1017 16058411 1% /dev tmpfs 16078645 1812 16076833 1% /run /dev/sda2 3276800 154963 3121837 5% / tmpfs 16078645 4 16078641 1% /dev/shm tmpfs 16078645 13 16078632 1% /run/lock tmpfs 16078645 18 16078627 1% /sys/fs/cgroup /dev/sda4 31162368 4308 31158060 1% /data /dev/sdb1 182939648 564 182939084 1% /data/container 然后查找哪里小文件特别多。 ...

删除文件后磁盘空间没释放，是因为文件被进程打开，进程还持有文件描述符。用 lsof | grep deleted 找到占用进程，最好的方法是在线清空文件。 现象 在 Linux 或者 Unix 系统中，通过 rm 或者文件管理器删除文件，磁盘空间却没有释放。 根因 通过 rm 删除文件，只是将它从文件系统的目录结构上解除链接（unlink），也就是说只是删除了文件和系统目录结构的链接。 如果文件在删除时是被打开的（有一个进程正在使用该文件，文件被进程锁定或者有进程一直在向这个文件写数据等）状态，那么进程将仍然可以读取该文件，进程还持有文件的文件描述符 fd，所以磁盘空间也就会一直被占用。 一个文件在文件系统中的存放分为两个部分：数据部分和指针部分。 指针位于文件系统的 meta-data 中，数据被删除后，这个指针就从 meta-data 中清除了； 而数据部分存储在磁盘中，数据对应的指针从 meta-data 中清除后，文件数据部分占用的空间就可以被覆盖并写入新的内容； 之所以出现删除文件后空间还没释放，就是因为有进程还在一直向这个文件写入内容，导致虽然删除了文件，但文件对应的指针部分由于进程锁定，并未从 meta-data 中清除； 而由于指针并未被删除，那么系统内核就认为文件并未被删除，因此通过 df 命令查询空间并未释放也就不足为奇了。 解决办法 1. 找到占用进程并 kill 通过 lsof | grep deleted 命令获取到已经被删除但是仍然被应用程序占用的文件列表，然后 kill 掉还在占用所删除文件的进程。 需要注意的是：如果有很多进程都在使用所删除文件，那么采用这种方式 kill 进程就有点麻烦了，而且风险也比较大。 因为 kill 进程是通过截断 proc 文件系统中的文件可以强制要求系统回收分配给正在使用的文件。 必须要确定不会对运行中的进程造成影响时才能使用，应用程序对这种方式支持的并不好，当一个正在使用的文件被截断可能会引发不可预知的问题。 2. 停掉或重启应用 停掉或重启使用这个所删除文件的应用，让 OS 自动回收磁盘空间。 3. 重启操作系统 也可以重启操作系统，不过这并不是最好的方法。 4. 在线清空文件（推荐） 对待这种进程不停对文件写日志的操作，要释放文件占用的磁盘空间，最好的方法是在线清空这个文件。 通过这种方法，磁盘空间不但可以马上释放，也可保障进程继续向文件写入日志。 在线清空文件（比如 /var/log/app.log）的方式： ...