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查看：先执行了：df -h...

wwoss

4283人浏览 · 2019-09-29 14:49:30

wwoss · 2019-09-29 14:49:30 发布

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

[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     .

和前面的查询结果对比着看，/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 [root@/]# lsof |grep delete
根据lsof列出的进程号,kill这些进程后,空间就释放出来了.
b. 暴力法，直接reboot，生产tranffic还没有切得情况下慎用（如果没有lsof又没有yum，又不能编译安装 lsof的情况下，只能reboot，或者你知道进程的pid直接kill掉）。

可能是磁盘的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大神的帮助

华为开发者空间

华为开发者空间，是为全球开发者打造的专属开发空间，汇聚了华为优质开发资源及工具，致力于让每一位开发者拥有一台云主机，基于华为根生态开发、创新。

更多推荐

解析openGauss账本数据库

华为开发者空间

GaussDB高智能--库内AI引擎：模型管理&数据集管理

华为开发者空间

GaussDB高智能--库内AI引擎：机器学习算法的训练和推理

华为开发者空间

所有评论(0)

查看更多评论

wwoss

@u014145985

已为社区贡献1条内容