我正在尝试清空我的syslog.1
文件,该文件充满了一些消息,大小为 77 GB。我做到了
sudo truncate -s 0 /var/log/syslog.1
但指挥部需要两个多小时才能返回。通过 Ctrl-C 或kill
命令停止它是否安全?恐怕这些方法可能会导致文件系统不一致。有没有更好的办法?
系统是Ubuntu 16.04。由于该文件以及和的大小突然增加,所在的根分区/var/log/syslog.1
几乎已满。后面的文件仍在继续增长,但命令行仍然有响应。/var/log/syslog
/var/log/kern.log
答案1
中断进程永远不会导致文件系统本身损坏。内核确保了这一点。最糟糕的情况是文件相对于应用程序不变量处于不一致的状态。例如,在保存文件时终止文件编辑器可能会留下写了一半的文件,但不会损坏其他文件。
该truncate
实用程序ftruncate
在幕后调用系统调用。这个系统调用是原子的:它要么发生,要么不发生。因此,如果您终止该truncate
进程,最终结果是文件处于原始状态,就好像truncate
尚未运行一样,或者文件被截断。您不能最终得到一个缩短但未完全截断的文件。
截断文件不会覆盖磁盘上的数据。它仅更新文件使用的块列表和空闲块列表。它不会更新数据块本身:当稍后回收它们来存储数据时,它们将被覆盖。即使文件很大,也不会花很长时间。在任何可能有空间容纳 77 GB 日志的硬件上,即使覆盖 77 GB 数据也不会花费数小时。所以很可能发生了一些不好的事情。您可能遇到了在完整磁盘上性能不佳的病态情况,但即便如此,我预计系统速度会减慢几秒钟,如果有其他东西以高优先级写入磁盘,则可能会减慢几分钟,而不是几个小时。更有可能的可能性是磁盘出了问题,而现在发现的这主要是巧合。检查内核日志:如果磁盘出现问题,您将看到有关它的消息。还要检查磁盘状态智能控制。
顺便说一句,syslog.1
它是一个存档文件,因此不会有其他内容写入其中。您最好将其删除而不是将其清空。
除非存在内核或硬件错误,但无论您是否终止进程,这种情况都可能发生。