我有一个正在运行的关键任务服务器，我无法关闭它（或者至少，我被告知现在不能关闭它）。
不幸的是它已经填满了它的根分区。
它正在运行一个自定义进程，正在编写一些日志文件，因为我主要是一名开发人员，所以我想修复程序记录日志的方式以使其与 logrotate 兼容，因为它现在还不兼容。
因此我需要说服首席开发人员，修复此问题值得，并且应成为高度优先事项。目前，我可以压缩日志并将它们 scp 到异地，因为它们需要长时间保存以供分析。但有些日子，服务器流量很大，日志中有大量数据填满磁盘，我才有机会做任何事情。一旦磁盘已满，压缩大文件而没有任何剩余空间是不可能的。而且由于它们很大，复制到另一台服务器可能需要相当长的时间。
所以我需要一些杠杆来帮助提高它的优先级。完整的根分区有什么副作用？
答案1
如果文件系统的其他部分位于其自己的分区上，则根分区已满的严重性可以稍微减轻一些。但是，想象一下，如果某个进程无法写入文件系统并收到错误，它会做什么。
举例来说，任何使用此机制的进程都无法创建 /var/run/*.pid 文件（但很多进程都这样做），它们应该无法启动或崩溃，或者它们可能会反复尝试启动，而由于没有 pid 文件而无法检测到它们已经启动并启动一个新实例，直到内存不足的终止进程启动并开始随机终止东西。
副作用包括但不限于
- 当管理员正在度假、熟睡等时，服务器半夜意外崩溃……
- 根据您自定义应用程序的编写方式，它可能无法以任何合理的方式处理崩溃，并会损坏自身，以至于您需要从备份中恢复。大多数开发人员在测试时首先想到的不是“如果我拔掉电源线会发生什么......现在！哇，这并没有杀死它，如果我这样做......现在”
您确实有备份吧……
需要多长时间
- 意识到你无法在任何合理的时间内恢复现有系统
- 可能设置一台新机器（这样你就可以拿出旧机器进行分析，以便恢复一些有希望的信息）
- 实际从备份恢复
管理层有多喜欢这种停机和数据丢失……？