一次磁盘空间清理的复盘

背景

在Linux机器上部署了一个http服务器，磁盘是100G，使用了nginx作为反向代理，并开启了access日志功能。

过程

某天登陆以后发现创建文件失败，提示空间不足了。 于是我用df命令看了一下，使用率确实达到了100%。

第一反应估计是nginx日志把硬盘写爆了，因为是个测试服务器，于是二话不说就去删除了access日志。

最后df再看一眼，What？？！还是100%使用率？！

真是一顿操作猛如虎，然并卵...

这就很奇怪了，于是开始逐个排查问题，首先是用du -h --max-depth=1命令查看根路径下一级目录和文件的存储占用:

$ du -h --max-depth=1 /
872K    /run
5.6G    /var
2.1G    /usr
1.3G    /mnt
...
9.3G    /

诡异的是，这时发现根目录的总占用只有9.3 G左右！这是什么鬼？

现在问题的关键是为什么df 和du命令的结果不一致呢？

于是google了一下，推测应该是被删除文件仍然被进程占用的缘故，于是使用网上说的如下命令进行了确认:

$ lsof -a +L1 
COMMAND     PID    USER   FD   TYPE DEVICE SIZE/OFF NLINK    NODE NAME
openresty   864  nobody    4w   REG  253,1 909429464760     0  659511 /mnt/fastmock/logs/access.log (deleted)
openresty   865  nobody    4w   REG  253,1 909429464760     0  659511 /mnt/fastmock/logs/access.log (deleted)
mysqld     2417 polkitd    4u   REG   0,38        0     0  659108 /tmp/ibAQqtrD (deleted)
mysqld     2417 polkitd    5u   REG   0,38        0     0  659454 /tmp/ib3mPnlj (deleted)
mysqld     2417 polkitd    6u   REG   0,38        0     0  659482 /tmp/ibiFOifZ (deleted)
...

注：在SIZE那一列显示了已经被删除文件的大小，而COMMAND和PID则可用帮助我们找到对应的进程。

确认是nginx（openresty）进程占用以后，我们必须重启对应进程以释放被占用的文件。由于日志文件实际上是被nginx的worker进程占用，所以这里不需要nginx服务，而只需用重栽命令重启worker进程即可。

$ openresty -s reload

再次使用lsof命令，可以确认之前被openresty占用的deleted文件已经释放：

$ lsof -a +L1 
mysqld     2417 polkitd    4u   REG   0,38        0     0  659108 /tmp/ibAQqtrD (deleted)
mysqld     2417 polkitd    5u   REG   0,38        0     0  659454 /tmp/ib3mPnlj (deleted)
mysqld     2417 polkitd    6u   REG   0,38        0     0  659482 /tmp/ibiFOifZ (deleted)
...

再用df命令确认一下存储空间， 原先被占用的空间已经彻底释放：

$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        99G  6.9G   87G   8% /

至此，问题解决！

根因

由于是在nginx运行过程中使用rm命令删除nginx的access日志，虽然你ls或者du上已经看不到对应的日志文件了，但是文件并没有被真正删除掉。在linux上，rm命令删除文件的方式是将文件从文件结构中进行unlink操作。

然而，如果这个文件是打开的（比如被进程使用），那么其实进程还是可以访问这些文件的，这也是为什么你在Linux上删除文件的时候不会出现类似windows的文件正被其他程序占用无法删除的提示，这些文件在占用的进程停止后才会真正被删除。

takeaway

这种蛮普通的trouble-shooting过程为什么要写篇文件来复盘呢？其实我觉得仔细分析下来还是有不少收获可以分享给大家的：

• 生产环境上请养成为日志配置翻转的习惯，搜索Linux的logrotateg功能会有详细的解析，这里放一个nginx的日志翻转配置供参考：

  $ cat /etc/logrotate.d/fastmock 
  /mnt/fastmock/logs/*.log {
      daily
      size 4k
      rotate 5
      compress
      copytruncate
      dateext
      sharedscripts
      postrotate
          /bin/kill -HUP `cat /usr/local/openresty/nginx/logs/nginx.pid 2> /dev/null` 2> /dev/null || true
      endscript
  }
  

• 使用truncate的方式来清理日志文件而不是直接删除， 比如：

  > logs/access.log
  

• 搜索时提出正确的问题会让你事半功倍，问题的关键现象是du和df结果不一致，所以我在搜索时是这样描述的：

  du show disk full but can't find
  

• du和dh的区别：

  根据手册描述df命令报告文件系统的磁盘使用率。

  df - report file system disk space usage

  而du命令则是估算文件的占用量。

  du - estimate file space usage

  du 工作在文件层面进行估算，对给定路径进行递归的文件大小统计。

  df 则是从文件系统层面进行估算，其结果直接内核调用的结果。

• 查看已被标记为deleted的文件，首先推荐用这个查看：

  lsof -a +L1 
  

  记不住的话可以用grep命令进行过滤， ：

  lsof ｜ grep deleted
  

  还有一种方法是直接用find命令进行文件查找：

  find /proc/*/fd -ls | grep  '(deleted)'