关于云计算:Linux磁盘空间怎么释放

0次阅读

共计 3072 个字符,预计需要花费 8 分钟才能阅读完成。

问题阐明

IDC 里的一台服务器的 / 分区使用率爆满了!已达到 100%!经查看发现有个文件过大(80G),于是在跟无关共事确认后 rm - f 果决删除该文件。然而发现删除该文件后,/ 分区的磁盘空间压根没有释放出来,使用率还是 100%!这是为什么呢?


[root@linux-node1 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                       58G  7.8G   47G  100% /
tmpfs                 1.9G     0  1.9G   0% /dev/shm
/dev/vda1             190M   72M  108M  40% /boot

起因剖析:

在 Linux 零碎中,通过 rm 或者文件管理器删除文件,只是将它会从文件系统的目录构造上解除链接 (unlink),也就是说只是删除了文件和系统目录构造的链接;

如果文件在删除时是被关上的(有一个过程正在应用该文件,文件被过程锁定或者有过程始终在向这个文件写数据等)状态,那么过程将依然能够读取该文件,也就是说没有删除掉文件在读取的状态,所以磁盘空间也就会始终被占用。

一个文件在文件系统中的寄存分为两个局部:数据局部和指针局部,指针位于文件系统的 meta-data 中,数据被删除后,这个指针就从 meta-data 中革除了,而数据局部存储在磁盘中,数据对应的指针从 meta-data 中革除后。

文件数据局部占用的空间就能够被笼罩并写入新的内容,之所以呈现删除文件后,空间还没开释,就是因为有过程还在始终向这个文件写入内容,导致尽管删除了文件,但文件对应的指针局部因为过程锁定,并未从 meta-data 中革除,而因为指针并未被删除,那么零碎内核就认为文件并未被删除,因而通过 df 命令查问空间并未开释也就难能可贵了。

解决措施有以下几种

  1. 通过 lsof|grep deleted 命令获取到曾经被删除然而依然被应用程序占用的文件列表,而后 kill 掉还在占用所删除文件的过程。须要留神的是:如果有很多过程都在应用所删除文件,那么采纳第 1 种形式 kill 过程就有点麻烦了,而且危险也比拟大。

    因为 kill 过程是通过截断 proc 文件系统中的文件能够强制要求零碎回收调配给正在应用的的文件。必须要确定不会对运行中的过程造成影响时能力应用,应用程序对这种形式反对的并不好,当一个正在应用的文件被截断可能会引发不可预知的问题。

  2. 或停掉或重启应用这个所删除文件的利用,让 OS 主动回收磁盘空间。
  3. 也能够重启操作系统,不过这并不是最好的办法
  4. 看待这种过程不停对文件写日志的操作,要开释文件占用的磁盘空间,最好的办法是在线清空这个文件。通过这种办法,磁盘空间岂但能够马上开释,也可保障过程持续向文件写入日志。

在线清空文件(比方 /home/wangshibo.log)的形式:


a)# echo " " > /home/wangshibo.log
b)# cat /dev/null > /home/wangshibo.log
c)# > /home/wangshibo.log

还有一种磁盘空间应用问题的景象:明明应用 df - h 命令查看磁盘空间使用率不算高,还有很多空余空间,然而创立文件或写入数据时始终报错磁盘写满:” no space left on device”!

个别这种问题都是因为分区目录下 deleted 删除后的资源空间没有真正释放出来导致的, 具体解决流程如下:

  • 先 df -lh 查看一下磁盘应用情况, 发现 /data 分区下的 Used 已用空间很大, 然而理论查看并没有占用那么大的空间!
  • 找到被删除文件所在的分区, 比方 /data 分区
  • 查看被删除了的所有文件:lsof -n /data |grep deleted
  • 杀死这些文件的 delete 过程, 开释空间: lsof -n /data |grep deleted|awk ‘{print $2}’|xargs kill -9
  • 接着再运行 lsof -n /data |grep delete,应该就没有后果了。
  • 留神: 刚杀死 deleted 过程时, df - h 查看 /data 分区, Used 已用空间可能时霎时显示过大, 但随着 deleted 过程杀死, 资源逐步开释, /data 分区下的 Used 已用空间会逐步变小, Avail 可用空间会逐步变大 )

大多数文件系统都会保留一部分空间留作紧急情况时用(比方硬盘空间满了),这样能保障有些要害利用(比方数据库)在硬盘满的时候有点余地,不致于马上就 crash,给监控零碎和管理员一点工夫去觉察。不过有时候这部分预留的硬盘空间不必的话有点节约。

在 Linux 零碎中,ext2、ext3、ext4 文件系统上通常会默认预留 5%的磁盘空间,比方磁盘如果是 2TB,这就意味着有 100GB 的空间会被预留下来,这样的话会不会显得有点节约了。能够通过 ”tune2fs” 命令来扭转 5%的默认设置,比方只预留 2%的空间。然而不倡议设成 0%,事实环境中这样做不平安。


[root@ss-server ~]# df -T
Filesystem     Type     1K-blocks    Used Available Use% Mounted on
/dev/vda1      ext4      41151808 4962148  34076228  13% /
devtmpfs       devtmpfs   1931468       0   1931468   0% /dev
tmpfs          tmpfs      1941204       0   1941204   0% /dev/shm
tmpfs          tmpfs      1941204     652   1940552   1% /run
tmpfs          tmpfs      1941204       0   1941204   0% /sys/fs/cgroup
tmpfs          tmpfs       388244       0    388244   0% /run/user/0

[root@ss-server ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G  4.8G   33G  13% /
devtmpfs        1.9G     0  1.9G   0% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           1.9G  620K  1.9G   1% /run
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
tmpfs           380M     0  380M   0% /run/user/0

比方下面 ”/” 分区是 ext4 文件系统,默认零碎预留了 5% 也就是 2G 的空间。当初能够通过 ”tune2fs” 命令将零碎预留空间改为 2%。

[root@ss-server ~]# tune2fs -m 2 /dev/vda1
tune2fs 1.42.9 (28-Dec-2013)
Setting reserved blocks percentage to 2% (209704 blocks)

执行后,发现 ”/” 分区腾出了 1G 的空间,这时零碎预留空间也就是 2% 了。

[root@ss-server ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G  4.8G   34G  13% /
devtmpfs        1.9G     0  1.9G   0% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           1.9G  620K  1.9G   1% /run
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
tmpfs           380M     0  380M   0% /run/user/0

留神:Linux 下只有 ext2、ext3、ext4 文件系统时,零碎才会默认预留 5% 的磁盘空间。如果文件系统是 xfs、tmpfs、devtmpfs、overlay 等,则零碎默认不会预留磁盘空间。

福利:豆花同学为大家精心整顿了一份对于 linux 和 python 的学习材料大合集!有须要的小伙伴们,关注豆花集体公众号:python 头条!回复关键词“材料合集”即可收费支付!

正文完
 0