我正在尝试清空我的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它是一个存档文件，因此不会有其他内容写入其中。您最好将其删除而不是将其清空。
除非存在内核或硬件错误，但无论您是否终止进程，这种情况都可能发生。