2014-04-07 13:42:39 +0000 2014-04-07 13:42:39 +0000
26
26

删除文件但磁盘空间仍然满了

处理老的CentOS 5.6盒子,没有设置lvm,我的根文件系统/已经满了,我已经清除了许多旧的日志文件和我不需要的应用程序文件,这些文件的大小超过了2 -5GB,但是我的系统仍然报告磁盘已满。

[root@tornms1 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 130G 124G 0 100% /
/dev/sdb1 264G 188M 250G 1% /data
/dev/sda1 99M 24M 71M 26% /boot
tmpfs 2.0G 0 2.0G 0% /dev/shm

[root@tornms1 ~]# mount
/dev/sda3 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sdb1 on /data type ext3 (rw)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

有什么办法可以让我下一步尝试做什么吗,很遗憾,重启盒子目前不是一个选择。

Risposte (9)

38
38
38
2014-04-07 14:02:13 +0000

这里可能发生了两件事。

第一 ,你的文件系统已经预留了一些空间,只有root可以写入,所以当普通用户用完磁盘空间时,关键的系统进程不会倒下。这就是为什么你看到130G中使用了124G,但可用空间为零。也许你删除的文件使利用率降到了这个点,但没有低于正常用户的阈值。

如果这是你的情况,而你又走投无路,你也许可以改变root的预留空间量。要将其减少到1%(默认值是5%),你的命令将是

# tune2fs -m 1 /dev/sda3

,操作系统不会为已删除但仍在打开的文件释放磁盘空间。如果你删除了(比如)Apache的一个日志文件,你需要重新启动Apache以释放空间。

18
18
18
2015-09-24 09:32:08 +0000

如果你删除了一个正在被进程使用的文件,你就不能再通过ls查看该文件。进程仍在向该文件写入,直到你停止该进程。

要查看那些被删除的文件,只需运行lsof|grep delete

10
10
10
2014-04-07 21:03:43 +0000

还有2种方法可以得到磁盘已满的问题:

1) hidden under a mount point: linux会显示一个满的磁盘,文件 “隐藏 "在mount point下。如果你有数据写到硬盘上,然后在上面挂载另一个文件系统,即使你看不到挂载点下的文件,linux也会正确地记录磁盘使用情况。如果你有nfs挂载,可以试着umounting它们,看看在挂载前是否有任何东西被意外地写入这些目录中。

2) 损坏的文件:我在windows到linux通过SMB传输文件时偶尔会看到这种情况。一个文件未能关闭文件描述符,你会得到一个4GB的垃圾文件。

这可能是比较繁琐的修复方式,因为你需要找到文件所在的子目录,但很容易修复,因为文件本身是很容易删除的。我使用du命令,对根目录下的子目录进行列举,找出文件空间被使用的地方。

cd /
du -sh ./*

顶层目录的数量通常是有限的,所以我设置人可读标志-h,看看哪个子目录是占用空间的。

然后你cd到问题子目录中,对其中的所有项目重复这个过程。为了便于发现大的项目,我们稍微改变了一下du,并将其与排序结合起来。

cd /<suspiciously large dir>
du -s ./* | sort -n

这将产生一个由最小到最大的所有文件和目录的字节大小的输出

4 ./bin 
462220 ./Documents
578899 ./Downloads
5788998769 ./Grocery List

一旦你发现了过大的文件,你通常可以直接删除它。

4
4
4
2014-04-07 14:27:52 +0000

你可以用lsof找出哪些文件被打开。它可以产生大量的输出,所以我在下面的例子中限制了以log结尾的行。

# lsof | grep log$
rsyslogd 2109 syslog 0u unix 0xffff88022fa230c0 0t0 8894 /dev/log
rsyslogd 2109 syslog 1w REG 252,6 62393 26 /var/log/syslog
rsyslogd 2109 syslog 2w REG 252,6 113725 122 /var/log/auth.log
rsyslogd 2109 syslog 3u unix 0xffff88022fa23740 0t0 8921 /var/spool/postfix/dev/log
rsyslogd 2109 syslog 5w REG 252,6 65624 106 /var/log/mail.log
/usr/sbin 2129 root 2w REG 252,6 93602 38 /var/log/munin/munin-node.log
/usr/sbin 2129 root 4w REG 252,6 93602 38 /var/log/munin/munin-node.log
...
1
1
1
2017-06-08 10:02:04 +0000

如果一些文件被删除,但仍被某些进程使用,那么它的空间将不会被释放。在这种情况下,要么重新启动一个正在使用该文件的进程,要么将该文件清零。它总是好的做法是使这些文件无效,而不是删除它们。要找到已删除的文件,但仍被某些进程使用,

#lsof +L1

它将给出进程id和文件描述符。通过文件描述符

#echo "" > /proc/$pid/fd/$fd
```来清空已删除的文件。
1
1
1
2020-02-27 01:18:39 +0000

在大多数情况下,如果我们删除任何日志文件,它不再通过ls查看文件。进程仍在向该文件写入,直到你停止进程。

1
1
1
2017-10-31 13:45:06 +0000

输入命令

#lsof +L1

这将会显示带有删除引号的内存文件列表。

注意文件的pid(进程id)

杀掉进程

#kill <pid>

内存将被进程释放

用命令

#df -h
```检查。
0
0
0
2016-06-02 09:58:41 +0000

在野外观察到的实际问题:

确保你删除的是实际的文件,而不是文件的symlinks。特别是对日志文件来说,这可能是个问题。

0
0
0
2016-01-23 08:00:36 +0000

除了上述的解释,问题可能是在同一台服务器的另一个连接的磁盘设备上有另一个被删除文件目录的挂载点。检查当前的挂载点和fstab条目。