我们有一个系统正在尝试进行故障测试。我正在运行的场景涉及模拟完整磁盘（具体来说是我们附加的记录器磁盘）。我已使用填充磁盘df -h来查看剩余空间（因此在此示例中假设为 4G），然后sudo fallocate -l 10G /opt/var/big.file生成一个文件直至达到限制。
当我这样做时，df我确实看到它Use%是 100% 并且Available是 0。但是，如果我转到我的日志目录，我会看到类似以下内容：
-rw-r--r-- 1 0 0 28M Nov 7 17:43 service.log
-rw-r--r-- 1 0 0 4.0K Nov 7 17:43 service.log-2017-11-07-17-13.gz
-rw-r--r-- 1 0 0 1.2K Nov 7 17:43 service.log-2017-11-07-17-14.gz
-rw-r--r-- 1 0 0 27M Nov 7 17:44 service.log-2017-11-07-17-15
-rw-r--r-- 1 0 0 0 Nov 7 17:44 service.log-2017-11-07-17-15.gz
-rw-r--r-- 1 0 0 1.3K Nov 7 17:40 service.log-2017-11-07-17-1.gz
-rw-r--r-- 1 0 0 28M Nov 7 17:41 service.log-2017-11-07-17-2
-rw-r--r-- 1 0 0 4.0K Nov 7 17:41 service.log-2017-11-07-17-3
如果我tail -f service.log可以看到正在附加数据。我还可以看到我的log4j2设置正在适当地旋转文件（尽管有几个文件直到稍后才显示为解压缩）。文件完成压缩后，日志将附加到活动日志文件的末尾。这就像我们写入日志的速度太快（DEBUG 日志记录已打开，每秒写入约 40M 的日志，并且旋转最大大小设置为 200M），以至于在收到请求之前无法完全压缩文件压缩另一个文件...或类似的东西。
我不知道该怎么做——有人能帮忙解释一下吗？
答案1
默认情况下 5% 的卷空间是为根保留关于格式。该卷上不再有用户空间，但日志正在由 root 写入。