一个日志功能一年烧掉一块固态硬盘

4月时, 就有用户反馈Codex日志写入量出现异常情况, 然而一直到6月23日, 此问题被推到News头条之后, 才获得正式处理。那位用户在清点硬盘之际发现, 机器持续开机21天, 主固态硬盘被写入了37TB的数据。正常的主流消费级固态硬盘标称的写入寿命大概在150到600TBW, 这足够普通用户使用十几年, 可是Codex的一个日志功能一年就能够写满。评论区当中有人进行神补刀: 审查流程怎么没有拦住如此明显的错误呢。

更让人觉得离谱的是, 写入的方式。Codex在本地维护着一个数据库, 这个数据库专门用来记录反馈日志。用户抓取了15秒的数据, 结果发现数据库被插入了36211行, 然而保留的总行数, 自始至终一个也没有增多。这套机制有个外号叫做“插入 – 删除”, 意思是插入之后立刻进行删除。更荒诞不经的事来了, 它记录的内容全都是文件系统事件, 同一个文件被同一个程序反反复复记录了十几万遍。日志里的自增ID已经超过了55亿, 真正留存下来的行却只有大约50万。

不占空间专烧寿命的隐形杀手

把这段话改为: 这便引出了关乎整件事情的最为违背常理认知的一个要点, 即固态硬盘的使用寿命所依据的是“写入量”, 并非“文件大小”。Codex运用的是WAL机制, 每当出现改动时, 首先会写入到-wal文件之中, 待积攒到一定程度后才会回写到主库。每一次在15秒的时间内要进行三万多次的插入以及删除操作, 而每一次操作都必须历经WAL、索引更新的过程, 同一存储区域会被反复地擦除。这同样是致使这个漏洞能够潜伏这么长时日的缘由所在, 也就是它并不占用空间, 仅仅是损耗寿命。通过查看可用磁盘无法察觉到异常状况, 文件大小始终没有变化, 唯有去读取硬盘自身的SMART健康计数, 才能够发现写入量在悄然不断地累积。

答案处于Codex源码的一行配置之中, 反馈日志的sink初始化之时所采用的是::new().(Level::TRACE), 简而言之, 日志默认开启至TRACE级别, 是最高级且最为繁琐、记录所有内容的那一档, Codex的日志框架属于Rust生态, 其标准做法是读取环境变量。用户自然是尝试过将其调整为 info、warn, 甚至是直接关闭的操作, 然而, 有一情况在这条处理体系中是, 把将(Level::TRACE)设定为全范围默认并强行紧固锁定固定处在追踪核实状态的, 在此路径范围情形以内一点一点都不会起到起效作用的状态情形。这种故障问题最具有令受涉及到的人感到坑害折腾人的地方因素就在于并不是那种情形是“你忘记疏漏了进行设定配置了呢样的情况”, 而是属于“你已经去执行了配置设定而它像是佯装呈现假装并没有在意去听察觉到这样的行为表现”的状况。

七成写入全是没人看的废话

将留存的日志依照类别予以拆分, TRACE占据了70.7%, 约为732.5MB。另外, 那两路镜像遥测日志再占了25.3%。七成的写入是TRACE噪声与镜像遥测相加, 96%全部都是无人会去看的废话。报告者查阅了Codex仓库, 发觉这类“日志无界增长”的Issue起码有9个。#17320流式响应期间WAL疯狂写入, 根原因和此次完全一样都是TRACE被无视。#12969是最早能追溯到的源头, 此源头正是那个将反馈日志的sink按照TRACE级别接入进来的PR。

一个大小为4KB的数据库, 被写成了每秒11MB, 单拿出来就足以写成一篇。而它跟640TB那个, 属于同一产品同一套遥测体系的症状。这表明Codex的日志以及遥测系统, 从一开始就不存在“资源预算”这个概念。整个赛道都在比拼token预算、较量上下文长度、竞争模型能力, 然而几乎没人去问: 一个常驻在用户机器上、7×24小时运行的Agent, 它的磁盘、内存、CPU预算该由谁来负责。

三个修复补丁只解决八成问题

6月14日的报上, 6月23日报告者进行了更新, 称三个PR已合并。就其自身Codex反馈而言, 能减少约85%的日志, 随后宣布关闭。在三个修复当中, #29432、#29457已随0.142.0发布, 砍掉了逐条日志以及噪声目标。第三个#29599呢, 会停掉另一类被桥接进来的冗余日志, 要等到0.143.0才上线。即便三个都到位了, 剩下约15%一年仍要写约96TB, 只是从“一年烧穿硬盘”降到了“六年烧穿硬盘”。

存在一些人替其进行辩护, 声称trace日志依据设计留存下来用于调试, 并非是bug, 没错, 着实便利对边缘情况展开追查。然而, 问题恰好就出在这个地方: 将付费用户的SSD寿命用于为厂商的debug提供免费存储, 这件事情用户是否同意过呢。评论区立刻有人进行补刀: Code也朝着本地大量写入调试日志, 有人无奈之下只好把日志目录通过软链连结到内存盘来延长SSD的寿命。社区里的评论迅速从一个bug扩展到了整个AI编程工具的质量问题。

软件越写越烂硬件越造越猛

存在着这样的情况, 有人针对这些智能体, 吐槽其GPU常年处于跑满的状态, 并且内存动不动就达到70GB, 还有人直接给这一代的软件取了个名字, 那便是: 劣质软件。那位开发者所提出的建议原本是极为简单的, 即: 给应用设置一条线, 使其不超过3GB。就是这样的一条线, Codex耗费了9个Issue, 过去了好几个月才勉强画下来。问题在于, 有这样一个时刻将“AGI”挂在嘴边的公司, 为何会在实习工程师都能够看出来的问题上栽跟头。为何这样的毛病能够隐藏如此之久, 有条评论倒是说到了关键之处? 放置在十年前，日志开到TRACE, 程序会当场卡死, 当天就会被修复掉。

现在, CPU的速度足够快, 内存的空间足够大, 磁盘的性能足够猛, 这点小毛病被硬件性能暗暗地消化掉了, 程序依旧能够运行, 界面仍然保持正常, 用户也没有什么感觉, 一直到有一天, SSD提前坏掉报废了。这两年来, 软件被AI生成的代码填得满满的, 功能越来越多, 抽象层越来越厚, 资源消耗一路飞速增长, 完全依靠硬件厂商每年推出更快的芯片来强力承载。于是出现了一个荒谬的循环: 软件编写得越来越糟糕, 硬件制造得越来越厉害。 用户带着“似乎没有变慢”的错误感觉掏钱去更换新机器, 实际上只是新机器勉强能够支撑住更差的软件。

竞品压力下快速响应只是入场券

可是, Codex与Code的竞争, 已从模型能力, 延伸至开发者工作流的入口。在这条战线上, 迅速作出改变, 去响应开发者需求, 向来不是加分项, 仅是入场券。Codex拖延两个多月, 才正视一个能烧穿SSD的bug, 并且用户还得自行撰写报告, 将其推上头条, 才会被重视。这样的态度, 置于AI编程工具争抢用户的市场中, 迟早会付出代价。毕竟, 开发者最为敏感的, 就是自身的开发环境被破坏。

最后问一下: 你有没有去查看一下自己专门存放Codex日志的那个目录究竟有多大呢? 在评论区域讲一讲你所发现的情况 , 点一下赞并且进行一次分享 , 好让更多的人避免掉入坑中。