Codex 狂写日志毁硬盘? 三种方案拯救你的 SSD 寿命

Codex 狂写日志毁硬盘? 三种方案拯救你的 SSD 寿命

发布时间: 2026-06-26
作者: DP
浏览数: 2,657 次
分类: 视频
支持内容
## A. Codex 内部检查和修复方法 > 1.1 Codex 自检提示词 ``` 帮我检测 ~/.codex/logs_2.sqlite 是否因 TRACE 日志持续高频写盘? ``` > 1.2 Codex 自动修复提示词 ``` 中招了就直接先备份,再用 SQLite trigger 拦截 logs 表, 并 checkpoint/truncate WAL,最后采样确认 MAX(id) 和 WAL 不再增长 ``` ## B. 命令行修复方法 > (目前推荐这个方法经过测试,写入的 log 数量非常的少) > 2.1 关闭 Codex 程序 > 2.2 运行命令 ``` sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;" ``` ## C. 内存存储 log 修复方法 >(当前出现了内存空间写满后,浏览器自动化测试异常的情况, 如果出现,请增大空间) > 3.1 dp_ramdisk_setup.sh // 修复问题脚本 MacOS 版本 ``` #!/bin/bash # --- 配置区 --- RAM_DISK_NAME="RAMDisk_DP" # _DP 后缀可以去掉,用途是防止重复。 # 分配 20MB (40960 扇区) , 1M = 2048 DISK_SIZE=$((2048 * 20)) MOUNT_PATH="/Volumes/$RAM_DISK_NAME" TARGET_LINK="$HOME/.codex/logs_2.sqlite" RAM_FILE="$MOUNT_PATH/logs_2.sqlite" echo "开始执行内存盘检查... dpit.lib00.com" # 1. 检查内存盘是否已经挂载 if mount | grep -q "on $MOUNT_PATH "; then echo "[OK] 内存盘 $RAM_DISK_NAME 已经挂载,跳过创建步骤。" else echo "[!] 内存盘未挂载,正在创建..." # 尝试创建内存盘 DISK_DEV=$(hdiutil attach -nomount ram://$DISK_SIZE) if [ $? -ne 0 ]; then echo "[ERROR] 无法分配内存空间,请检查系统资源。" exit 1 fi diskutil erasedisk HFS+ "$RAM_DISK_NAME" $DISK_DEV echo "[OK] 内存盘创建成功。" fi # 2. 确保内存盘内的目标文件存在 if [ ! -f "$RAM_FILE" ]; then echo "[!] 内存盘中不存在日志文件,正在初始化..." touch "$RAM_FILE" echo "[OK] 目标文件已创建。" else echo "[OK] 内存盘中的日志文件已存在。" fi # 3. 检查并处理软链接 if [ -L "$TARGET_LINK" ]; then # 如果已经是软链接,检查指向是否正确 CURRENT_DEST=$(readlink "$TARGET_LINK") if [ "$CURRENT_DEST" == "$RAM_FILE" ]; then echo "[OK] 软链接已存在且指向正确,无需操作。" else echo "[!] 软链接指向了错误的位置 ($CURRENT_DEST),正在修复..." rm "$TARGET_LINK" ln -s "$RAM_FILE" "$TARGET_LINK" echo "[OK] 软链接已更新。" fi elif [ -f "$TARGET_LINK" ]; then # 如果是一个普通文件(不是链接),说明是程序生成的真实日志,需要替换 echo "[!] 发现同名真实文件,正在移动到内存盘..." # 建议先删除或备份,这里选择直接删除以符合你的“无意义日志”需求 rm "$TARGET_LINK" ln -s "$RAM_FILE" "$TARGET_LINK" echo "[OK] 真实文件已替换为内存盘软链接。" else # 如果文件不存在 echo "[!] 软链接不存在,正在创建..." ln -s "$RAM_FILE" "$TARGET_LINK" echo "[OK] 软链接创建成功。" fi echo "所有检查完成,环境已就绪。" ``` > 3.2 给予脚本执行权限。 // 替换 [PathTo] 为真实路径 ``` chmod +x [PathTo]dp_ramdisk_setup.sh ``` > 3.3 运行脚本 // 替换 [PathTo] 为真实路径 ``` [PathTo]dp_ramdisk_setup.sh ``` ## D. 开机自动运行 C 内存修复方案 // MacOS 版本 > 4.1 新建开机运行脚本 ``` nano ~/Library/LaunchAgents/com.dpit.ramdisk.plist ``` > 4.2 填充内容 ``` <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.dpit.ramdisk</string> <key>ProgramArguments</key> <array> <string>[PathTo]dp_ramdisk_setup.sh</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist> ``` > 4.3 加载开机运行 ``` launchctl load ~/Library/LaunchAgents/com.dpit.ramdisk.plist ``` ## E. links > 5.1 github issue A ``` https://github.com/openai/codex/issues/28224 ``` > 5.2 github issue B ``` https://github.com/openai/codex/issues/17320 ``` > 5.3 github release v0.142.0 ``` https://github.com/openai/codex/releases/tag/rust-v0.142.0 ```
总结内容
# Codex 狂写日志毁硬盘? 三种方案拯救你的 SSD 寿命 在这期视频中, 博主 DP 深入探讨了 Codex APP 运行时的一个严重缺陷: **海量日志写入问题**, 并分享了三种解决方案, 帮助用户保护昂贵的 SSD 硬盘. ## 💥 核心问题: 被疯狂吞噬的 SSD 寿命 - **恐怖的写入量**: 有 GitHub 网友反馈, Codex 在短短 21 天内写入了高达 37TB 的日志数据. 这意味着它一年的写入量可达 640TB, 足以报废一块常见的 1TB 固态硬盘 (设计寿命约 600TBW) . - **TBW 科普**: TBW (Total Bytes Written) 是衡量固态硬盘寿命的关键指标, 达到设定阈值即意味着硬盘寿命终结. - **官方修复未果**: 尽管 Codex 官方在 0. 412 版本 (Issue 29432) 声称修复了日志问题, 但实际测试发现 log 文件依然在飞速膨胀. 只是发送一句 "Hi", 底层日志就能暴增数兆字节. --- ## 🛠️ 三大解决方案 视频给出了 A, B, C 三种解决方案, 兼顾了小白和极客用户: ### 方案 A & B: 程序级过滤方案 - **方案 A**: 直接在 Codex 里让 AI 自检, 并要求其屏蔽日志相关写入. - **方案 B**: 关闭 Codex, 通过特定的命令行指令阻挡相关维度的写入. - **弊端**: 这两种方法都强绑定当前的 `logs_2` 文件, 一旦该文件被初始化, 删除或重建, 修复就会立即失效, 无法治本. ### 方案 C: 终极内存盘 (Ramdisk) 方案 (UP主原创) 既然问题出在持续不断的磁盘写入上, 那么只要把写入目标转移到**不怕擦写且重启即清空**的内存上即可. 1. **创建内存盘**: 通过 shell 脚本在内存中划分一块极小的空间 (如 20MB) . 2. **构建软链接**: 删除原本位于 SSD 上的日志文件, 将日志路径通过 `ln -s` 指向内存盘里新建的文件. 3. **彻底免疫**: Codex 依然会疯狂写无用的日志, 但所有的写入消耗都发生在了高速内存层面, 对 SSD 寿命的损耗瞬间降为 0. 4. **自动化重启机制**: 利用 Mac 系统的 `plist` 启动项进行配置, 每次开机自动划拨内存并建立软链接, 做到真正的全自动无感防护. --- ## 💡 总结与衍生启发 - 这一硬盘损耗问题不仅仅存在于 Codex APP 端, 相关的 CLI 工具和 VS Code 插件同样受其影响. - 建议用户立刻采取补救措施. 博主提供的 **方案 C (内存虚拟盘转移法) ** 展示了极佳的极客思维. 这种方法也是一种极好的衍生思想, 随时可以无缝迁移到未来任何疯狂写入垃圾日志的“流氓软件”上.
关联内容
相关推荐
2025家庭网络升级方案分享
2025家庭网络升级方案分享
06:25 | 266次

2025年家庭网络升级方案分享,分享思路,希望一次抛砖引入,欢迎大家一起来分享自己的优秀方案。

远行星号 0.98a 终极新手入门指南: 安装 + 汉化 + MOD, 一步到位!
远行星号 0.98a 终极新手入门指南: 安装 + 汉化 +...
00:00 | 3,616次

还在为《远行星号》0.98a的入门而烦恼吗? 本视频是你的终极解决方案! 主播DP手把手教你如何下载...

群晖DSM修改登录端口,新手教程.更安全.包教包会
群晖DSM修改登录端口,新手教程.更安全.包教包会
01:23 | 214次

如何在群晖DSM系统中修改登录网页端口,以提升安全性的新手教程。新手教程针对新手用户,争取做到包教包...

Antigravity 最新配额实测:Pro变试用? Ultra从 1500 降到 250? 付费订阅者该何去何从?
Antigravity 最新配额实测:Pro变试用? Ult...
00:00 | 754次

本视频深入测试了谷歌 AI IDE Antigravity 的最新配额。我们发现无论是 Pro 还是...