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檢視：

先執行了：df -h

[[email protected]-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%.

[[email protected] ~]#cd /
   [[email protected] /]#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     .

和前面的查詢結果對比着看，/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

/home占用1.7G，同樣也是挂載到别的磁盤下的
剩下占用最大的就是/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有以下幾種猜測：

可能是沒有kill程序，直接rm程序占用的檔案，導緻程序還拿着檔案的句柄沒有釋放，這種情況有兩種結局方法：

a. 用lsof檢查，有檔案被删除,而程序還活着,因而造成還占用空間的現象
javasript [[email protected]/]# lsof |grep delete
根據lsof列出的程序号,kill這些程序後,空間就釋放出來了.

b. 暴力法，直接reboot，生産tranffic還沒有切得情況下慎用（如果沒有lsof又沒有yum，又不能編譯安裝 lsof的情況下，隻能reboot，或者你知道程序的pid直接kill掉）。

可能是磁盤的inode用完了

[[email protected] ~]# 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.可能挂載的有問題（檢查了挂載點，人頭擔保沒問題）

[[email protected]-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

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

真相就在：

[[email protected] cassandra]# df -h ./data/

Filesystem Size Used Avail Use% Mounted on

/dev/vda2 9.8G 9.6G 237M 98% /

[[email protected] cassandra]# du -sh ./data/

4.7G ./data/

嗯~這就是真兇了

合

總結一下：/var/cassandra/data/ 這個目錄在沒有挂載到新磁盤的時候是預設是和根目錄同在一個分區的，産生的資料和根目錄共享同一塊容量，但是重新挂載後，又沒有将之前産生的資料删除掉（4.7G的真兇),挂載新磁盤後資料全都寫到了新磁盤，df指令可以查到它的影子卻查不到它的位置，du 指令能查到新檔案産生的位置，影子卻找不到，是以感覺仿佛丢了4.7G，但是卻又存在。删掉它後，reboot重新挂載案子就破了。。。查了百度很多文章都沒有看到相似的問題，希望以後遇到相同的問題能給大家思路。

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

linux 根目錄被沾滿找不到原因，仿佛丢了4.7Glinux 根目錄被沾滿找不到原因，仿佛丢了4.7G

linux 根目錄被沾滿找不到原因，仿佛丢了4.7G

起

9.6-4.9=4.7G?

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

轉

合

繼續閱讀

linux 挂載_運維丨linux如何挂載CD光牒

檢視linux cpu和記憶體使用率

linux 挂載_UBUNTU挂載硬碟時報錯LINUX_RAID_MEMBER

在linux挂載一個新硬碟的完整步驟

linuxCD光牒及U盤等挂載指令

linux(suse)系統時間的同步和修改

linux裡挂載（mount）和取消挂載（umount）指令

Linux挂載硬碟到home目錄下

Ubuntu系統下ntp伺服器搭建安裝步驟問題解決

Linux下挂載系統鏡像

Linux系統管理-（2）--磁盤的挂載與解除安裝

linux挂載本地yum源——centos7.9為例

linux挂載_Linux如何挂載最新的exfat格式u盤

《我的Linux成長之路（七）------Linux挂載和永久挂載及擴充(增加交換分區、硬碟大于2T等)》

Linux系統下常用指令及快捷操作

Linux系統管理---挂載外部裝置、統計檔案或者檔案夾大小