Codex日志疯狂写盘怎么办：3个止血办法保护SSD

最近有用户发现，Codex日志在流式传输和自动化任务场景下，可能出现异常高频写盘。最夸张的情况是以接近 5MB/s 的速度持续往磁盘写日志，长期下来对消费级SSD并不友好。

如果你的机器最近出现磁盘占用异常、日志文件持续变大，建议先别急着重装，先确认是不是 Codex日志 在疯狂增长。

先判断是不是中招 🔍

最直接的方法，就是看看日志文件是否还在持续变大，再统计一下日志级别分布。只要 TRACE 占比特别高，而且文件大小一直涨，基本就能说明问题不小。

ls -lh ~/.codex/logs_2.sqlite
sqlite3 ~/.codex/logs_2.sqlite "SELECT level, COUNT(*) FROM logs GROUP BY level ORDER BY COUNT(*) DESC"

如果结果里 TRACE 明显占大头，且日志文件几分钟内就增长很多，就要尽快处理，避免继续消耗SSD写入寿命。

止血办法一：直接阻止日志写入

这是最硬的一招，适合先救火。原理很简单：给 sqlite 加一个触发器，直接拦截日志表插入，让它别再写了。

这种方式的好处是立刻见效，坏处是会把诊断日志一起关掉。好在这里存的不是对话历史，主要是运行诊断信息，所以通常可以接受。

sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"

如果你现在只想先让SSD停下来，这个办法最省事。

止血办法二：把日志文件放进内存盘

如果你不想彻底禁用日志，可以把日志文件软链到 tmpfs内存盘，让它在内存里写。这样就算日志继续刷，也不会继续磨SSD。

这个方案很适合临时过渡，尤其是你还想保留日志功能做排查的时候。缺点也很清楚：重启后内容会清空，但对于临时止血来说完全够用。

mv ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.bak
ln -s /tmp/logs_2.sqlite ~/.codex/logs_2.sqlite

如果机器内存够用，这种方式既保留了日志行为，又避免了对系统盘的持续写入。

止血办法三：挪到机械硬盘或备用盘

如果家里有第二块机械硬盘，或者有一块不那么在意写入寿命的盘，也可以直接把日志文件挪过去。机械盘虽然慢一点，但耐写，适合承接这种高频日志。

这个思路比较稳，不需要复杂改造，也不用担心内存盘重启丢失问题。适合长期观察问题是否已经被修复，或者等后续版本优化。

为什么建议优先处理

很多人会低估日志爆写的影响。短时间看不出问题，但如果长期以高频率持续写入，SSD 的磨损会非常快。尤其是消费级硬盘，本来就不是按这种日志量设计的。

如果你的机器上已经观察到 TRACE 数量异常、日志文件持续膨胀，那就别拖。先止血，再排查，最后再决定保留日志还是彻底关闭。

实用建议：先查、再停、最后观察

• 先确认日志文件是否在持续增长。
• 再统计 TRACE、DEBUG、INFO 的占比。
• 如果 TRACE 占多数，优先选择触发器拦截或内存盘方案。
• 如果需要保留日志排障，就把文件迁移到更耐写的存储介质。

这类问题的关键不在“会不会影响体验”，而在“会不会悄悄伤硬盘”。只要处理得早，通常都能把损失降到最低。

如果你也发现 Codex 日志一直涨，建议先按上面的办法处理，再观察一段时间。能止住写盘，SSD 就算是保住了。