Một năm "ăn" hết một ổ SSD 1TB?
Codex, công cụ lập trình hàng đầu của OpenAI, đang "đốt cháy" ổ cứng thể rắn (SSD) của bạn với lượng ghi 640TB mỗi năm.
Gần đây, một nhà phát triển đã gửi một báo cáo lỗi (issue) lên GitHub. Issue GitHub này hiện được đánh dấu "Đã đóng", mang số hiệu #28224, với tiêu đề:
Nhật ký phản hồi SQLite của Codex có thể ghi 640TB một năm, nhanh chóng cạn kiệt tuổi thọ ổ SSD.
Theo thử nghiệm thực tế của người báo cáo, ổ SSD chính của anh ta đã bị ghi mất 37TB sau 21 ngày chạy liên tục, ngoại suy ra một năm là khoảng 640TB, đủ để làm hỏng một ổ cứng tiêu dùng có Tổng Dung lượng Ghi (TBW) là 600TB.
Để chứng minh, anh ta đã đăng hai bảng.
Trong bằng chứng 1, cơ sở dữ liệu nhật ký này luôn chỉ có 1,2GB, bề ngoài trông như không có gì xảy ra; nhưng ID hàng tự động tăng (auto-increment) của nó đã lên tới 5,5 tỷ, trong khi số hàng thực sự được giữ lại chỉ hơn 500 nghìn, chênh lệch tới cả vạn lần.
Điểm mấu chốt là, hao mòn ổ cứng chỉ tính tổng lượng đã ghi, bất kể hiện tại còn lại bao nhiêu: 5,5 tỷ hàng này đều đã được ghi xuống đĩa, việc xóa chúng đi cũng không lấy lại được lượng ghi đã tiêu tốn. Vì vậy, bạn tra cứu file sẽ luôn chỉ thấy 500 nghìn hàng đó, nhưng ổ cứng đã phải gánh chịu lượng ghi của 5,5 tỷ hàng.
Bằng chứng 2 tiết lộ sự phân bố của 5,5 tỷ hàng này: hơn chín phần mười là các thông tin gỡ lỗi (debug noise) mà ngay cả nhà phát triển cũng sẽ không xem lại, chỉ riêng việc sao chép toàn bộ từng gói dữ liệu WebSocket đã chiếm một nửa.
Thủ phạm là một cấu hình mặc định Level::TRACE, nó đã coi tuổi thọ ghi của ổ cứng bạn như giấy nháp miễn phí.
Một bình luận được ủng hộ cao trên Hacker News đã trực tiếp định tính sự việc này:
Đây là một trong những ví dụ "khét tiếng" nhất của "phần mềm kém chất lượng" (slopware).
Người dùng này còn bất lực thốt lên một câu:
Đây thực sự là một bi kịch. Thế giới này cần có người cạnh tranh với Anthropic.
Đáng ngại hơn, vấn đề này không phải không có ai báo cáo.
Từ tháng 4 năm nay đã có những phản hồi rải rác, kéo dài hơn hai tháng, phải đợi đến khi người dùng tự đo đạc, viết báo cáo, đưa nó lên trang nhất Hacker News, mới được xử lý nghiêm túc. Thậm chí như vậy, đợt này cũng chỉ cắt giảm được khoảng 85% lượng ghi nhật ký.
Có người muốn tự tay sửa, nhưng lại phát hiện không có cách nào: phiên bản desktop của những công cụ này là mã đóng.
Phần bình luận còn có một câu "thần thánh": Quy trình kiểm duyệt sao lại không ngăn được một lỗi hiển nhiên như vậy? À đúng rồi...... @codex hãy kiểm duyệt cái này đi.
640TB, rốt cuộc được ghi ra như thế nào
640TB là khái niệm gì?
Ổ SSD tiêu dùng phổ biến, tuổi thọ ghi danh định (TBW) khoảng 150 đến 600 TBW, đủ cho người dùng thông thường dùng hơn mười đến hai mươi năm.
Trong khi đó, chức năng nhật ký "ghi lại những gì mình đã làm" của Codex, một năm đã có thể ghi đầy.
Sự việc bắt đầu từ việc người dùng này kiểm tra ổ cứng. Máy của anh ta chạy liên tục 21 ngày, ổ SSD chính đã bị ghi mất 37TB.
Theo tốc độ này, một năm khoảng 640TB.
Điều vô lý hơn là cách thức ghi.
Codex duy trì một cơ sở dữ liệu SQLite cục bộ tên là logs_2.sqlite, chuyên để ghi nhật ký phản hồi. Người dùng này bắt trong 15 giây — cơ sở dữ liệu được chèn vào 36211 hàng, trong khi tổng số hàng được giữ lại, từ đầu đến cuối đều là 681774, không hề tăng thêm.
Mỗi hàng được chèn vào, thì có một hàng bị xóa đi. Số hàng luôn không đổi, nhưng đĩa cứng lại bị ghi xóa qua lại vài chục nghìn lần.
Cơ chế này có một biệt danh, gọi là insert-and-prune: chèn vào, rồi lập tức xóa bớt.
Điều phi lý hơn là nó ghi lại cái gì: một đống sự kiện inotify của hệ thống file.
ld.so.cache được ghi 128764 lần, locale.alias 37982 lần, passwd 23843 lần.
Cùng một file, bị cùng một chương trình, ghi đi ghi lại hàng trăm nghìn lần.
ID tự tăng trong nhật ký đã vượt quá 5,5 tỷ, trong khi số hàng thực sự được giữ lại chỉ khoảng 500 nghìn.
Chênh lệch cả vạn lần.
Đây không phải là bug, mà giống như một công cụ lập trình AI đang tụng kinh liên hồi vào chính ổ cứng của mình.
File chỉ 1GB, lượng ghi lại là 640TB
Vừa ghi vừa xóa, file logs_2.sqlite còn lại sẽ lớn bao nhiêu? Khoảng 1GB.
Điều này dẫn đến điểm phản trực giác nhất của toàn bộ sự việc: tuổi thọ SSD xem xét "lượng ghi" (write amount), chứ không phải "kích thước file". Một file 1GB bị ghi xóa 640 lần, đối với ổ cứng tương đương với việc đã ghi 640TB.
SQLite sử dụng cơ chế WAL, mỗi lần thay đổi trước tiên được ghi vào file -wal, tích đủ rồi mới checkpoint về cơ sở dữ liệu chính. Codex cứ 15 giây thực hiện hơn ba mươi nghìn lần chèn cộng xóa, mỗi lần đều phải trải qua WAL, cập nhật chỉ mục, checkpoint, cùng một vùng lưu trữ, bị xóa đi viết lại liên tục.
Ví dụ: một cuốn sổ tay 1GB, mỗi ngày bạn xóa đi viết lại 1750 lần, viết liên tục một năm. Cuốn sổ vẫn là cuốn đó, nhưng giấy đã bị mòn thủng.
Đây cũng là lý do bug này có thể ẩn náu lâu như vậy: nó không chiếm không gian, chỉ đốt tuổi thọ.
Kiểm tra dung lượng đĩa khả dụng không thấy bất thường, kích thước file luôn yên tĩnh, chỉ có khi đọc bộ đếm sức khỏe SMART của chính ổ cứng, mới thấy lượng ghi đang âm thầm tích lũy.
Nguyên nhân gốc, một dòng RUST_LOG bị bỏ qua
Tại sao lại ghi nhiều nhật ký như vậy?
Câu trả lời nằm trong một dòng cấu hình của mã nguồn Codex: sink của nhật ký phản hồi SQLite, khi khởi tạo, sử dụng Targets::new().with_default(Level::TRACE).
Nói một câu, nhật ký mặc định mở ở cấp TRACE, mức cao nhất, dài dòng nhất, ghi lại mọi thứ.
Khung nhật ký của Codex là tracing trong hệ sinh thái Rust, cách làm chuẩn là đọc biến môi trường RUST_LOG. Người dùng tất nhiên đã thử, điều chỉnh RUST_LOG thành info, warn, thậm chí tắt hẳn.
Vô ích.
with_default(Level::TRACE) đã cứng hóa mặc định toàn cục ở TRACE, RUST_LOG trên đường dẫn này hoàn toàn không có hiệu lực. Bạn tưởng mình đã tắt nhật ký, nó vẫn ghi như thường.
Loại bug này khiến người ta bực nhất ở chỗ, không phải là "bạn quên cấu hình", mà là "bạn đã cấu hình, nó giả vờ không nghe thấy".
Chói mắt hơn là một tỷ lệ.
Chia nhật ký được giữ lại theo loại, TRACE chiếm 70,7%, khoảng 732,5 MB. Cộng thêm hai luồng nhật ký telemetry gương codex_otel (log_only và trace_safe), lại chiếm thêm 25,3%.
Bảy phần mười lượng ghi là noise TRACE, cộng với telemetry gương, 96% toàn là những lời vô nghĩa không ai xem.
Chỉ có 4%, mới là nội dung thực sự có ý nghĩa.
Đây không phải là cái đầu tiên, ít nhất là cái thứ chín
Người báo cáo đã lục lại kho lưu trữ Codex, phát hiện loại Issue "nhật ký tăng trưởng vô hạn" này, ít nhất có 9 cái.
#17320, WAL ghi điên cuồng trong thời gian phản hồi theo luồng, nguyên nhân gốc giống hệt lần này, đều là TRACE bỏ qua RUST_LOG.
#24275, logs_2.sqlite phiên bản desktop tăng điên cuồng.
#22444, WAL tăng vô hạn và còn chiếm không gian không giải phóng.
#26374, một ngày ghi 0,75GB, không xoay vòng.
#27911, một goals_1.sqlite 4KB, bị ghi thành 11MB/s.
#20563, tiến trình rảnh rỗi cũng ghi đĩa điên cuồng.
#27020, trên Windows hoạt động đĩa 100%.
Nguồn gốc sớm nhất có thể truy về #12969, chính PR này đã kết nối sink nhật ký phản hồi SQLite ở cấp TRACE.
Một cơ sở dữ liệu 4KB bị ghi thành 11MB mỗi giây, đứng riêng ra cũng đủ viết một bài. Và nó cùng với cái 640TB kia, là triệu chứng của cùng một sản phẩm, cùng một hệ thống telemetry.
Điều này cho thấy hệ thống nhật ký và telemetry của Codex, ngay từ đầu đã không có khái niệm "ngân sách tài nguyên".
Cả phân khúc đều đang đua nhau về ngân sách token, độ dài ngữ cảnh, năng lực mô hình.
Nhưng hầu như không ai hỏi: một Agent chạy thường trực trên máy người dùng, hoạt động 7×24 giờ, ngân sách đĩa, bộ nhớ, CPU của nó, ai quản lý?
Đã sửa, nhưng sửa theo kiểu rất OpenAI
Ngày 14 tháng 6 báo lên GitHub, ngày 23 tháng 6, người báo cáo cập nhật một dòng: ba PR đã được hợp nhất, theo phản hồi Codex của chính anh ta có thể giảm khoảng 85% nhật ký, nên tuyên bố đóng lại.
Trước tiên nói về 85% này — không phải 100%, và chưa triển khai hết.
Trong ba bản sửa lỗi, #29432, #29457 đã được phát hành cùng phiên bản 0.142.0, cắt bỏ nhật ký WebSocket từng dòng và các mục tiêu noise; bản thứ ba #29599 dừng một loại nhật ký dư thừa khác được cầu nối vào, phải đợi đến 0.143.0 mới ra mắt.
Ngay cả khi cả ba đều đến nơi, phần còn lại khoảng 15%, một năm vẫn phải ghi khoảng 96TB, chỉ là từ "một năm đốt cháy ổ cứng" giảm xuống "sáu năm đốt cháy ổ cứng".
Cũng có người biện hộ cho nó: nhật ký trace là được lưu lại theo thiết kế để debug, không tính là bug, và đối với OpenAI cũng thực sự tiện để truy tìm các trường hợp biên.
Nhưng vấn đề chính là ở đây: lấy tuổi thọ SSD của người dùng trả phí, làm bộ lưu trữ miễn phí cho việc debug của nhà sản xuất, việc này, người dùng đã đồng ý chưa?
Chiến trường lập trình, bị đốt cháy không chỉ SSD
Thú vị là, bị chỉ tên không chỉ có Codex.
Phần bình luận ngay lập tức có người bổ đao: Claude Code cũng ghi nhật ký debug vào máy cục bộ dữ dội, có người đành phải liên kết mềm (soft link) thư mục nhật ký đến ổ đĩa RAM (tmpfs) để kéo dài tuổi thọ SSD.
Hai hãng hàng đầu, phạm cùng một loại sai sót.
Bình luận trong cộng đồng, nhanh chóng từ một bug, được phóng đại thành vấn đề chất lượng của toàn bộ công cụ lập trình AI.
Có người phàn nàn các tác nhân thông minh này GPU thường xuyên chạy hết công suất, bộ nhớ động tay 70GB, có người thẳng thừng đặt tên cho thế hệ phần mềm này: phần mềm kém chất lượng.
Đề xuất của nhà phát triển đó vốn rất đơn giản: đặt một giới hạn cho ứng dụng, đừng vượt quá 3GB. Chỉ một đường giới hạn này, Codex kéo dài 9 Issue, mấy tháng trời mới chịu vạch ra.
Vấn đề là một công ty luôn đem "AGI" ra treo trên miệng, tại sao lại vấp ngã ở vấn đề mà ngay cả kỹ sư thực tập cũng có thể nhìn ra?
Tại sao căn bệnh này có thể ẩn náu lâu như vậy, một bình luận cũng nói đúng trọng tâm.
Đặt mười năm trước, nhật ký mở TRACE, chương trình lập tức đơ, ngay hôm đó đã được sửa; ngày nay CPU đủ nhanh, bộ nhớ đủ lớn, đĩa cứng đủ mạnh, điểm bệnh này bị hiệu năng phần cứng âm thầm tiêu hóa, chương trình vẫn chạy, giao diện vẫn bình thường, người dùng không cảm nhận được, cho đến một ngày SSD hỏng sớm.
Hai năm nay, phần mềm bị nhồi đầy mã do AI tạo ra, chức năng càng chất đống, tầng trừu tượng càng xếp cao, mức tiêu thụ tài nguyên tăng vọt, toàn dựa vào các nhà sản xuất phần cứng mỗi năm dùng chip nhanh hơn để cứng đỡ.
Vì thế có một vòng luẩn quẩn phi lý: phần mềm viết càng ngày càng tệ, phần cứng chế tạo càng ngày càng mạnh. Người dùng mang theo ảo giác "hình như không chậm hơn" rút tiền mua máy mới, thực chất chỉ là máy mới cố gắng chịu đựng phần mềm tệ hơn.
Một bug nhỏ tất nhiên không thể đè bẹp OpenAI. Nhưng cuộc cạnh tranh giữa Codex và Claude Code đã từ năng lực mô hình, lan rộng đến lối vào quy trình làm việc của nhà phát triển.
Trên chiến tuyến này, thay đổi nhanh chóng, đáp ứng nhu cầu của nhà phát triển không bao giờ là điểm cộng, mà chỉ là vé vào cửa.
Tài liệu tham khảo:
https://github.com/openai/codex/issues/28224
https://news.ycombinator.com/item?id=48626930
Bài viết từ tài khoản công chúng WeChat "Tân Trí Nguyên", tác giả: ASI Khải Thị Lục
