linux 根目錄被沾滿找不到原因，彷彿丟了4.7G

linux 根目錄被沾滿找不到原因，彷彿丟了4.7G

起

系統：SMP Wed Dec 19 10:46:58 EST 2018 x86_64 x86_64 x86_64 GNU/Linux
主機：3個node 的kvm虛擬機

系統收到告警，node-2 磁盤 / 目錄的佔用率98%，系統開始出現問題，於是把tranffic切到standby，ssh到node-2查看：

1. 先執行了：df -h

[root@rmeda1-2 ~]# df -h
Filesystem                        Size  Used Avail Use% Mounted on
/dev/vda2                         9.8G  9.6G  240M  98% /
devtmpfs                           15G     0   15G   0% /dev
tmpfs                              15G     0   15G   0% /dev/shm
tmpfs                              15G  129M   15G   1% /run
tmpfs                              15G     0   15G   0% /sys/fs/cgroup
/dev/vdb2                          57G  2.3G   55G   5% /var/cassandra/data
/dev/vdb1                         9.4G   44M  9.3G   1% /var/cassandra/commitlog
/dev/vda1                         997M  252M  746M  26% /boot
/dev/mapper/volgroup00-lv_home     15G  1.8G   13G  12% /home
/dev/mapper/volgroup00-lv_varlog  9.8G  3.0G  6.8G  31% /var/log
/dev/mapper/volgroup00-lv_tmp     2.0G   35M  2.0G   2% /tmp
tmpfs                             3.0G     0  3.0G   0% /run/user/1001
tmpfs                             3.0G     0  3.0G   0% /run/user/0

可以看出系統沒有誤報，確實根目錄使用率達到了98%.
2. 切到根目錄下查看，每個目錄下的大小

   [root@rmeda1-2 ~]#cd /
   [root@rmeda1-2 /]#du -ah --max-depth=1
	219M    ./boot
	0       ./dev
	1.7G    ./home
	du: cannot access ‘./proc/20709/task/20709/fd/4’: No such file or directory
	du: cannot access ‘./proc/20709/task/20709/fdinfo/4’: No such file or directory
	du: cannot access ‘./proc/20709/fd/3’: No such file or directory
	du: cannot access ‘./proc/20709/fdinfo/3’: No such file or directory
	0       ./proc
	129M    ./run
	0       ./sys
	1.9M    ./tmp
	5.4G    ./var
	39M     ./etc
	44M     ./root
	3.7G    ./usr
	0       ./bin
	0       ./sbin
	0       ./lib
	0       ./lib64
	0       ./media
	0       ./mnt
	878M    ./opt
	0       ./srv
	0       ./.autorelabel
	13G     .

3. 和前面的查詢結果對比着看，/var 目錄佔用最多5.4G，但是一下三個目錄總量差不多也有5.4G了，而且是掛載到別的磁盤下的，意味着這5.4G並沒有包含在/目錄的9.8G裏的。

/dev/vdb2                          57G  2.3G   55G   5% /var/cassandra/data
/dev/vdb1                         9.4G   44M  9.3G   1% /var/cassandra/commitlog
/dev/mapper/volgroup00-lv_varlog  9.8G  3.0G  6.8G  31% /var/log

4. /home佔用1.7G，同樣也是掛載到別的磁盤下的
5. 剩下佔用最大的就是/usr目錄了佔用3.7G，我們做個減法題：13-5.4-1.7=5.9G，再減去/boot,/temp…意味着實際的佔用了大約4.9G，但是爲什麼df 命令查出來佔用是9.6G？

9.6-4.9=4.7G?

神奇的4.7G去哪裏了呢？
經過baidu，google有以下幾種猜測：

1. 可能是沒有kill進程，直接rm進程佔用的文件，導致進程還拿着文件的句柄沒有釋放，這種情況有兩種結局方法：
   a. 用lsof檢查，有文件被刪除,而進程還活着,因而造成還佔用空間的現象
   javasript [root@/]# lsof |grep delete
   根據lsof列出的進程號,kill這些進程後,空間就釋放出來了.
   b. 暴力法，直接reboot，生產tranffic還沒有切得情況下慎用（如果沒有lsof又沒有yum，又不能編譯安裝 lsof的情況下，只能reboot，或者你知道進程的pid直接kill掉）。
2. 可能是磁盤的inode用完了

      [root@rmeda1-2 ~]# df -i
      Filesystem                         Inodes  IUsed    IFree IUse% Mounted on
      /dev/vda2                         5120000 113077  5006923    3% /
      devtmpfs                          3832094    454  3831640    1% /dev
      tmpfs                             3839395      1  3839394    1% /dev/shm
      tmpfs                             3839395    764  3838631    1% /run
      tmpfs                             3839395     16  3839379    1% /sys/fs/cgroup
      /dev/vdb2                        29719552   6406 29713146    1% /var/cassandra/data
      /dev/vdb1                         4882432     34  4882398    1% /var/cassandra/commitlog
      /dev/vda1                          512000    332   511668    1% /boot
      /dev/mapper/volgroup00-lv_varlog  5120000    798  5119202    1% /var/log
      /dev/mapper/volgroup00-lv_tmp     1024000    122  1023878    1% /tmp
      /dev/mapper/volgroup00-lv_home    7680000    239  7679761    1% /home
      tmpfs                             3839395      1  3839394    1% /run/user/1001
      tmpfs                             3839395      1  3839394    1% /run/user/0
   

3.可能掛載的有問題（檢查了掛載點，人頭擔保沒問題）

	[root@rmeda1-2 data]# cat /etc/fstab
	#
	# /etc/fstab
	# Created by anaconda on Sun Mar  3 18:26:42 2019
	#
	# Accessible filesystems, by reference, are maintained under '/dev/disk'
	# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
	#
	UUID=ad426056-7b1e-406e-9bb6-cdffcce1c2db /                       xfs     defaults        0 0
	UUID=469e1b49-396c-4154-966d-d444bd805046 /boot                   xfs     defaults        0 0
	/dev/mapper/volgroup00-lv_home /home                   xfs     nodev           0 0
	/dev/mapper/volgroup00-lv_tmp /tmp                    xfs     nodev,nosuid    0 0
	/dev/mapper/volgroup00-lv_varlog /var/log                xfs     defaults        0 0
	UUID=6a9980e7-aaf5-4c1f-bb2e-0f90f8e53e24 swap                    swap    defaults        0 0
	/tmp /var/tmp none bind 0 0
	/dev/vdb1       /var/cassandra/commitlog        xfs     defaults,nofail,comment=cloudconfig     0       0
	/dev/vdb2       /var/cassandra/data     xfs     defaults,nofail,comment=cloudconfig     0       0

我的情況正好是情況b.沒有lsof命令，只能reboot了，但是reboot了好幾次，你見，或者不見我，9.6G還在那裏。。。。
顯然我的inode還是很多的，所以以上猜測全盤否定。
如果還有4.5.6…請大佬指教。

就這樣陷入了我找不到4.7G的你，而你卻在那裏的僵局。。。

轉

請來大神Leo幫忙看看
大神看完也是一臉茫然，但是大神還是見多識廣
大神決定將

/dev/vdb2                          57G  2.3G   55G   5% /var/cassandra/data
/dev/vdb1                         9.4G   44M  9.3G   1% /var/cassandra/commitlog
/dev/mapper/volgroup00-lv_varlog  9.8G  3.0G  6.8G  31% /var/log

這些個目錄umount掉，爲什麼是這幾個目錄，因爲對比其他node發現這個目錄的佔有率變數最大，其中
57G 2.3G 55G 5% /var/cassandra/data的佔用才2.3G，而別的node都30~G了，很顯然Cassandra的數據存儲一致性除了問題。
於是Leo將/dev/vdb2 57G 2.3G 55G 5% /var/cassandra/data umount

[root@rmeda1-2 cassandra]# df -h ./commitlog/
	Filesystem      Size  Used Avail Use% Mounted on
	/dev/vda2       9.8G  9.6G  237M  98% /
	[root@rmeda1-2 cassandra]# df -h ./data/
	Filesystem      Size  Used Avail Use% Mounted on
	/dev/vda2       9.8G  9.6G  237M  98% /
	[root@rmeda1-2 cassandra]# df -h ./saved_caches/
	Filesystem      Size  Used Avail Use% Mounted on
	/dev/vda2       9.8G  9.6G  237M  98% /
	[root@rmeda1-2 /]# umount /var/cassandra/data/
	[root@rmeda1-2 /]# umount /var/cassandra/commitlog/
	[root@rmeda1-2 cassandra]# du -sh ./commitlog/
	2.2M    ./commitlog/
	[root@rmeda1-2 cassandra]# du -sh ./data/
	4.7G    ./data/

真相就在：
[root@rmeda1-2 cassandra]# df -h ./data/
Filesystem Size Used Avail Use% Mounted on
/dev/vda2 9.8G 9.6G 237M 98% /
[root@rmeda1-2 cassandra]# du -sh ./data/
4.7G ./data/
嗯~這就是真兇了

合

總結一下：/var/cassandra/data/ 這個目錄在沒有掛載到新磁盤的時候是默認是和根目錄同在一個分區的，產生的數據和根目錄共享同一塊容量，但是重新掛載後，又沒有將之前產生的數據刪除掉（4.7G的真兇),掛載新磁盤後數據全都寫到了新磁盤，df命令可以查到它的影子卻查不到它的位置，du 命令能查到新文件產生的位置，影子卻找不到，所以感覺彷彿丟了4.7G，但是卻又存在。刪掉它後，reboot重新掛載案子就破了。。。查了百度很多文章都沒有看到相似的問題，希望以後遇到相同的問題能給大家思路。

                                                                  ------感謝 leo大神的幫助