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

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

发布时间: 2026-06-26
作者: DP
浏览数: 0 次
分类: 视频
支持内容
## A. Codex 内部检查和修复方法 > 1.1 Codex 自检提示词 ``` 帮我检测 ~/.codex/logs_2.sqlite 是否因 TRACE 日志持续高频写盘? ``` > 1.2 Codex 自动修复提示词 ``` 中招了就直接先备份,再用 SQLite trigger 拦截 logs 表, 并 checkpoint/truncate WAL,最后采样确认 MAX(id) 和 WAL 不再增长 ``` ## B. 命令行修复方法 > 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 (内存虚拟盘转移法) ** 展示了极佳的极客思维. 这种方法也是一种极好的衍生思想, 随时可以无缝迁移到未来任何疯狂写入垃圾日志的“流氓软件”上.
关联内容
相关推荐
群晖DDNS设置方法,公网ip绑定自己域名,群晖7.2.1
群晖DDNS设置方法,公网ip绑定自己域名,群晖7.2.1
11:17 | 223次

群晖7.2.1系统设置DDNS,使公网IP(v4)和域名进行绑定的全过程记录。

docker容器使用代理,解决网络问题。群晖7.2使用docker
docker容器使用代理,解决网络问题。群晖7.2使用doc...
06:27 | 357次

群晖Nas中,docker容器配置使用代理解决网络无法访问的问题。如果你在使用docker中出现了网...

Docker版Nginx免费SSL证书. 永不过期.群晖Nas
Docker版Nginx免费SSL证书. 永不过期.群晖Na...
16:17 | 398次

基于群晖7.2.1系统,如何将docker版acme.sh生成的可续签且支持泛域名解析的SSL证书,...

Google Antigravity 账号解封指南, 官方解封教程来了(附唯一申诉入口)
Google Antigravity 账号解封指南, 官方解...
00:00 | 896次

你的 Google 全新 AI IDE Antigravity 账号是否意外被封禁? 本视频将为你提...