1. Từ "đầy ổ đĩa" đến "thủ phạm ẩn sâu": Không chỉ đơn giản là hết dung lượng

Chắc hẳn nhiều bạn khi làm việc với Docker đã từng gặp phải lỗi đỏ đáng sợ: no space left on device. Phản ứng đầu tiên thường là "ổ đĩa đầy rồi", sau đó vội vàng đi xóa file. Nhưng bạn có biết không? Đằng sau lỗi tưởng chừng đơn giản này có thể ẩn chứa nhiều "thủ phạm" khác nhau. Nếu chỉ tập trung vào dung lượng ổ đĩa, bạn có thể đi sai hướng và vấn đề vẫn không được giải quyết. Trong quản lý cụm container ở môi trường production, tôi đã từng mất nhiều thời gian chỉ vì suy nghĩ theo lối mòn và phát hiện ra một "kẻ giết người vô hình" khác.

Nguyên nhân trực tiếp nhất của lỗi này thực sự là do phân vùng ổ đĩa chứa thư mục dữ liệu của Docker (mặc định là /var/lib/docker) không còn dung lượng trống. Khi Docker kéo image, tạo container, build image hoặc container sinh ra log, nó đều cần ghi dữ liệu vào thư mục này. Khi hết dung lượng, mọi thao tác ghi đều thất bại. Tuy nhiên, bên dưới hiện tượng "hết dung lượng" này có ít nhất hai trường hợp hoàn toàn khác nhau: một là dung lượng khối (Block) thông thường hết, hai là inode (index node) hết. Bạn có thể hình dung dung lượng khối như các kệ hàng trong kho để chứa dữ liệu file, còn inode như danh mục quản lý hàng hóa. Kệ hàng đầy thì hàng mới không có chỗ để; nhưng dù kệ còn trống, nếu danh mục (inode) đã hết ô, bạn cũng không thể đăng ký hàng mới, và hệ thống vẫn báo "hết chỗ".

Vì vậy, khi gặp lỗi này, đừng vội vàng rm -rf. Một hướng xử lý chuyên nghiệp nên là: đầu tiên xác định vấn đề, sau đó dọn dẹp, cuối cùng tối ưu hóa. Tiếp theo, tôi sẽ hướng dẫn bạn từng bước phân tích mọi khía cạnh của vấn đề, từ các thao tác cấp cứu nhanh đến các giải pháp lâu dài, giúp bạn loại bỏ hoàn toàn lỗi phiền toái này.

2. Bước một: Chẩn đoán chính xác, tìm ra "thủ phạm thực sự"

Khi có cảnh báo, việc đầu tiên không phải là hành động mù quáng, mà giống như bác sĩ khám bệnh, hãy kiểm tra tổng thể hệ thống. Dưới đây là hai lệnh cốt lõi bạn phải nắm vững.

2.1 Kiểm tra mức sử dụng dung lượng khối

Đây là kiểm tra thông thường nhất. Sử dụng lệnh df -h để xem tình trạng sử dụng ổ đĩa của các điểm gắn kết. Điều quan trọng là tìm phân vùng chứa thư mục dữ liệu Docker.

df -h /var/lib/docker

Sau khi thực thi, bạn sẽ thấy kết quả tương tự:

Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p1  100G   98G  2.0G  98% /var/lib/docker

Hãy chú ý đến cột Use%. Nếu nó hiển thị 95% hoặc thậm chí 100%, thì nguyên nhân chính là thiếu dung lượng ổ đĩa thông thường. Điều này thường do tích tụ quá nhiều image cũ, container đã dừng, build cache vô dụng hoặc log container tăng không kiểm soát.

2.2 Kiểm tra mức sử dụng inode

Đây là bước quan trọng mà nhiều người bỏ qua. Ngay cả khi df -h cho thấy còn nhiều dung lượng trống, lỗi vẫn có thể xảy ra do inode hết. Lệnh kiểm tra là df -i.

df -i /var/lib/docker

Ví dụ kết quả:

Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/nvme0n1p1  6.5M    6.5M      0  100% /var/lib/docker

Lần này hãy chú ý đến cột IUse%. Nếu nó gần hoặc đạt 100%, vấn đề nằm ở đây. Điều gì khiến inode hết? Nguyên nhân phổ biến nhất là có quá nhiều file nhỏ. Trình điều khiển lưu trữ Overlay2 của Docker khi tổ chức các lớp image sẽ tạo ra rất nhiều file nhỏ. Đặc biệt, nếu bạn build image thường xuyên, hoặc chạy các ứng dụng tạo nhiều file tạm nhỏ (ví dụ: một số thành phần log, dịch vụ cache), rất dễ làm tiêu hao hết inode.

Một case thực tế: Nhóm tôi có một dịch vụ, mỗi instance container tạo ra hàng trăm file trạng thái nhỏ mỗi phút. Ở môi trường test chạy vài ngày không sao, nhưng khi lên production, số lượng container tăng lên, chưa đầy một ngày đã báo lỗi no space left.