我该如何阻止这种可用空间的持续丢失？

Question 1

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

如果某个文件在你眼前不断增大，而你不知道哪个程序正在写入该文件，那么你也许能够轻松发现这一点。下面是一个例子。谁打开了/var/log/syslog？我们使用以下fuser命令：

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

只有一个进程处于/var/log/syslog打开状态。它是进程 602。那是什么？我们不用考虑ps和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。您还可以设置基于日期的检查间隔。

现在要强制检查，您可以覆盖实际的count 大于或等于最大值，然后重新启动。这是用大写字母C:完成的tune2fs -C 1234 /dev/whatever。现在分区看起来好像已经挂载了 1234 次而没有检查，这大于一位或两位数的最大值。

Answer

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

如果某个文件在你眼前不断增大，而你不知道哪个程序正在写入该文件，那么你也许能够轻松发现这一点。下面是一个例子。谁打开了/var/log/syslog？我们使用以下fuser命令：

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

只有一个进程处于/var/log/syslog打开状态。它是进程 602。那是什么？我们不用考虑ps和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。您还可以设置基于日期的检查间隔。

现在要强制检查，您可以覆盖实际的count 大于或等于最大值，然后重新启动。这是用大写字母C:完成的tune2fs -C 1234 /dev/whatever。现在分区看起来好像已经挂载了 1234 次而没有检查，这大于一位或两位数的最大值。

Question 2

磁盘检查释放了一些空间，这表明这个问题（或部分问题）可能是由于文件系统损坏造成的。如果是这样，那么您应该能够通过扫描和修复文件系统来释放更多空间。但是，如果损坏持续发生（可能是也可能不是），这通常意味着硬盘驱动器快要坏了。如果您的备份（您的文档和任何其他难以替换的重要文件）不是完全最新的，请立即备份所有重要内容！

去检查和修复磁盘无法安装（至少无法读写）。因此，您应该从实时环境（实时 CD/DVD 或 USB）运行修复实用程序。首先，您必须找出包含文件的分区的设备名称。

所以，在已安装的系统中，跑步：

mount | grep ' on / '

/（请确保在和之间留有空格'。）

你会得到类似这样的信息：

/dev/sda8 on / type ext4 (rw,errors=remount-ro)

on以我的机器为例，前面的文本/dev/sda8是根分区的完整设备名称 ( /)。记下来，您会需要它。

然后从 Ubuntu 桌面 CD/DVD 或 USB 闪存驱动器启动您的计算机，就像您最初安装 Ubuntu 时所用的那样。（如果这是使用 Windows 安装程序安装的 Wubi 系统，请告诉我们。考虑到您所报告的情况，我并不指望这一点，但如果是这种情况，程序将会有所不同。）

选择无需安装即可试用 Ubuntu（不是安装 Ubuntu）。当您获得正常运行的桌面时，按++Ctrl打开终端窗口。然后运行以下命令：AltT

sudo e2fsck -fkccp /dev/sda8

但一定要更换/dev/sda8使用您分区的正确完整设备名称/，如您通过上面详述的方法获得的。

这可能需要一段时间。c该命令中包含的选项会扫描磁盘表面的错误以及文件系统（并将任何坏区域标记为坏区域，以便不使用它们）。cc如果您愿意，可以省略（如果您愿意，也可以省略k），但我建议保留它们。

e2fsck如果认为尝试修复某些问题很可能会导致数据丢失，系统可能会提示您修复这些p问题。（这使得它可以修复所有有信心可以修复而不会造成复杂情况的问题。）

我建议你强烈倾向于允许它修复任何它想要修复的问题，因为你只需要这样做后确保您的备份是最新的无论如何。如果您希望它在不提示您的情况下尝试修复潜在的危险，请将替换p为y。

此后，重新启动 Ubuntu 系统并查看是否有释放空间。如果不是，或者问题仍然存在，请评论并编辑您的问题以提供详细信息。

Answer