我如何阻止这种不断丢失的可用空间？

Question

我像往常一样运行 Ubuntu，突然出现一个对话框，说我只剩下 1.2 GB 的可用空间。一个小时前，我有 30 GB 的可用空间。

我删除了一些东西并将可用空间增加到 25 GB。但它继续减少。我尝试删除旧的日志文件和截断日志文件等，它继续减少！

我尝试使用磁盘分析器来查找所有这些可用空间损失的来源，但没有奏效，因为它显示了应有的所有内容。我重新启动并最终 Ubuntu 进行了磁盘检查，以某种方式将可用空间恢复到 40 GB，但它仍然每天继续减少约 10 GB。我继续尝试寻找释放空间的新方法，但这就像一个自动减少磁盘空间的过程，我无法停止。

我不知道该怎么办。如何找到原因，并阻止我的可用空间减少？

这是来自的输出sudo du -sh /var/* ~/.xsession-errors：

13M /var/backups
204M    /var/cache
112M    /var/crash
4.0K    /var/games
503M    /var/lib
4.0K    /var/local
0       /var/lock
9.5G    /var/log
85M     /var/mail
4.0K    /var/metrics
24K     /var/opt
0       /var/run
1.7M    /var/spool
391M    /var/tmp
11G     /var/tvmobili
20K     /var/www
224K    /home/school/.xsession-errors

Answer 1

你有一些失控的日志。与其每天疯狂删除，不如找到快速增长的一个或多个文件，然后查看内部调查可能导致这种情况的原因。也许某些程序正在循环记录某些条件。要么禁用该程序，禁用其日志记录，要么尝试修复它所抱怨的情况。

如果一个文件在您眼前不断增长，而您不知道哪个程序正在写入它，您可能会很容易找到它。这是一个例子。谁/var/log/syslog开了？我们使用fuser命令：

# fuser /var/log/syslog
/var/log/syslog:      602

只有一个进程/var/log/syslog打开。这是进程602。那是什么？让我们不要理会psand grep，而是/proc直接查看文件系统：

# ls -l /proc/602/exe
lrwxrwxrwx 1 root root 0 Mar 29 17:45 /proc/602/exe -> /usr/sbin/rsyslogd

啊哈，是rsyslogd。我们并不感到惊讶，rsyslogd有/var/log/syslog/开放。

不保证此方法有效。原因是程序不必为了写入文件而保持文件打开。假设您有一个进程打开一个文件，附加到它，然后关闭它。您将进行更困难的调查。您可以运行fuser多次，直到您偶然发现“红手”过程。这个过程本身可能会很快进入和消失。另一个问题是多个进程可以打开文件，但只有一个进程使它变大。在这种情况下，您可以跟踪他们的系统调用。

# fuser /var/log/huge-annoying-file
/var/log/huge-annoying-file:   1234 23459

哎呀！两个进程打开了它：1234 和 23459。让我们看看它们在做什么：

# strace -p 1234
Process 1234 attached - interrupt to quit
select(1, NULL, NULL, NULL, {9, 922666}

它什么都不做，只是在select通话中阻塞。Ctrl-C 中断跟踪：

select(1, NULL, NULL, NULL, {9, 922666}^C <unfinished ...>

检查下一个：

# strace -p 23459
write(5, "Useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
^C

哎呀，那个一直在写。那一定是坏的。我们甚至可以检查进程写入的文件描述符 5 实际上是大文件：

# ls -l /proc/23459/fd/5
lr-x------ 1 root root 64 Apr  3 23:39 /proc/23459/fd/5 -> /var/log/huge-annoying-file

我不怀疑您的文件系统已损坏，但要强制进行全面检查，您不必启动 DVD。

首先，查看文件系统的最大挂载计数设置。使用 df 命令识别您的分区。我在这里的 Ubuntu 系统上的示例：

# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda1       18062108 5499320  11645284  33% /
udev              392152       4    392148   1% /dev
tmpfs             159768     768    159000   1% /run
none                5120       0      5120   0% /run/lock
none              399416     200    399216   1% /run/shm
/dev/sr0           43668   43668         0 100% /media/VBOXADDITIONS_4.1.4_74291

您可以看到/文件系统安装在/dev/sda1. 所以/dev/sda1是根分区（和在该特定系统中唯一的分区）的存储装置。

让我们看看该文件系统的一些属性。即使已安装，这样做也是安全的。该命令会产生大量输出。这是摘录：

$ dumpe2fs /dev/sda1
dumpe2fs 1.42 (29-Nov-2011)
Filesystem volume name:   <none>
Last mounted on:          /
[ ... SNIP ... ]
Last mount time:          Fri Mar 29 17:45:18 2013
Last write time:          Tue Mar  5 09:08:03 2013
Mount count:              22
Maximum mount count:      22
[ ... SNIP ... ]

嘿看，挂载数等于最大挂载数。下次我重新启动时，将进行文件系统检查。重要的是安装计数是一个正值。如果您的为零，请使用 将其更改为某个正值，例如 22 tune2fs -c 22 /dev/whatever。零意味着无论分区安装多少次都不会强制进行检查。很少重新启动的系统在这里应该具有较低的值。每年宕机一次的服务器每次重新启动时可能会使用 fsck。您还可以设置基于日期的检查间隔。

现在要强制检查，您可以将实际计数覆盖为大于或等于最大值，然后重新启动。这是用资本完成的C：tune2fs -C 1234 /dev/whatever。现在该分区看起来像是未经检查就挂载了 1234 次，这大于一位或两位数的最大值。