- 服务报错,提示没有足够磁盘空间.

  • 登录服务器,使用df -h 查看磁盘空间使用率(此台为模拟,真实服务器使用率100%)

  • 在根目录下使用du -sh *, 查看各文件夹大小, 发现其实这些文件加一起也占不到服务器磁盘空间40G的一半

(使用du -sh * | sort -rh命令,对各文件按大小排序,更加直观)

(外记:du -h --max-depth=1,用于查看当前目录各文件占用大小)

  • 看到 cannot access 'proc/4086/task/4086/fd/4': No such file or directory, 很自然想到会不是这里的问题,最后发现实际是一条歧路,/proc目录有时可能会很大,甚至140T,但这个数字既不是磁盘空间,也不是内存空间.可将该目录简单理解为一个”运行中心”,是一个位于内存中的伪文件系统(in-memory pseudo-file system).该目录下保存的不是真正的文件和目录,而是一些“运行时”信息.linux中许多工具的数据来源正是proc目录中的内容

更多关于/proc的信息,可参见如下:

- 继续追查,谷歌到很多类似症状,大概答案是:

通过rm或者文件管理器删除文件,只是将它会从文件系统的目录结构上解除链接(unlink),也就是说只是删除了文件和系统目录结构的链接;如果文件在删除时是被打开的(有一个进程正在使用该文件,文件被进程锁定或者有进程一直在向这个文件写数据等)状态,那么进程将仍然可以读取该文件,也就是说没有删除掉文件在读取的状态,所以磁盘空间也就会一直被占用。

一个文件在文件系统中的存放分为两个部分:数据部分和指针部分,指针位于文件系统的meta-data中,数据被删除后,这个指针就从meta-data中清除了,而数据部分存储在磁盘中,数据对应的指针从meta-data中清除后,文件数据部分占用的空间就可以被覆盖并写入新的内容,之所以出现删除文件后,空间还没释放,就是因为有进程还在一直向这个文件写入内容,导致虽然删除了文件,但文件对应的指针部分由于进程锁定,并未从meta-data中清除,而由于指针并未被删除,那么系统内核就认为文件并未被删除,因此通过df命令查询空间并未释放也就不足为奇了。

  • 使用lsof | grep deleted,果然是好几屏的 已删除文件的磁盘读写操作进程

参见:


  • 8G/20G,约为20%

总结

  • 重启服务器或kill pid方式都能解决该问题

记录排查&解决这个问题中涉及到的一些命令及延伸

lsof

查看文件大小&&排序