Xử Lý Tình Trạng Đầy Inode VPS Linux: Chẩn Đoán & Dọn Dẹp

Xử lý tình trạng đầy inode là kỹ năng quản trị bắt buộc khi máy chủ Linux đột ngột báo lỗi No space left on device dù lệnh df -h vẫn hiển thị ổ cứng còn hàng chục GB dung lượng trống. Sự cố này khiến website ngưng trệ, dịch vụ cơ sở dữ liệu bị sập và hệ thống từ chối ghi mọi dữ liệu mới. Đội ngũ kỹ thuật tại ThueVPSGiaRe.vn sẽ hướng dẫn bạn quy trình chẩn đoán chính xác bằng dòng lệnh, dọn dẹp an toàn các thư mục chiếm dụng và thiết lập cơ chế tự động phòng ngừa triệt để trên Ubuntu/Debian.

Inode là gì? Tại sao VPS lại bị đầy inode khi ổ cứng vẫn còn trống?

Inode (Index Node) là một cấu trúc dữ liệu trên hệ thống tệp tin Linux dùng để lưu trữ toàn bộ thông tin siêu dữ liệu (metadata) của một tệp hoặc thư mục, bao gồm quyền truy cập, kích thước, thời gian tạo và vị trí các khối dữ liệu thực tế trên ổ đĩa cứng. Mỗi tệp tin hoặc thư mục riêng lẻ bắt buộc phải sử dụng đúng một inode.

Hệ điều hành Linux quản lý tài nguyên lưu trữ thông qua hai chỉ số độc lập: dung lượng khối dữ liệu vật lý (tính bằng Byte/GB) và tổng số lượng inode có thể cấp phát.

Khi định dạng phân vùng (format) theo các chuẩn tệp tin phổ biến như ext4, hệ thống sẽ cố định trước một lượng inode nhất định dựa trên dung lượng tổng.

Nếu VPS của bạn lưu trữ hàng triệu tệp tin siêu nhỏ (chẳng hạn mỗi tệp chỉ vài byte hoặc 0 byte), toàn bộ bảng chỉ mục inode sẽ bị lấp đầy 100% trước khi dung lượng GB thực tế chạm ngưỡng giới hạn.

Tiêu chí so sánh	Đầy dung lượng lưu trữ (Disk Space)	Đầy chỉ mục tập tin (Full Inode)
Lệnh kiểm tra	df -h	df -i hoặc df -ih
Bản chất nguyên nhân	Kích thước tệp lớn (Video, Database dump, Backup tar.gz)	Số lượng tệp quá lớn (Session PHP, Email spool, Cache nhỏ)
Thông báo lỗi hệ thống	No space left on device (ENOSPC)	No space left on device (ENOSPC)
Dấu hiệu nhận diện	Cột Use% trong df -h đạt 100%	Cột IUse% trong df -i chạm 100% dù Use% còn thấp

Kiểm tra inode trên VPS Linux: Hướng dẫn đọc lệnh df -i

Để xác định chính xác VPS có đang rơi vào tình trạng quá tải chỉ mục tệp hay không, bạn cần mở cửa sổ Terminal kết nối SSH và chạy lệnh kiểm tra chuyên biệt cho bảng inode.

df -ih

Tham số -i (inodes) yêu cầu hệ thống liệt kê thông tin bảng chỉ mục thay vì kích thước block lưu trữ, trong khi cờ -h (human-readable) giúp hiển thị các đơn vị số lượng dưới dạng K (nghìn), M (triệu) cho dễ đọc:

Filesystem     Inodes  IUsed  IFree IUse% Mounted on
udev             485K    420   485K    1% /dev
tmpfs            492K    850   491K    1% /run
/dev/vda1        2.5M   2.5M      0  100% /
tmpfs            492K      1   492K    1% /dev/shm

Hãy chú ý kỹ các cột hiển thị trong kết quả trả về:

• Filesystem: Tên định danh phân vùng ổ đĩa (ví dụ: /dev/vda1 hoặc /dev/nvme0n1p1).
• Inodes: Tổng số lượng inode được cấp phát tối đa cho phân vùng đó.
• IUsed: Số lượng inode đã bị các tệp tin và thư mục tiêu thụ.
• IFree: Số lượng inode còn trống có thể tiếp tục sử dụng.
• IUse%: Tỷ lệ phần trăm inode đã dùng. Nếu phân vùng gốc / hiển thị 100%, hệ thống sẽ lập tức chặn việc tạo tệp mới.

Cách tìm thư mục chiếm nhiều inode nhất trên Linux

Sau khi phát hiện phân vùng bị đầy chỉ mục, bước tiếp theo là xác định vị trí thư mục nào đang chứa số lượng tệp đột biến. Lệnh du -sh thông thường chỉ đếm dung lượng dung lượng MB/GB nên hoàn toàn vô hiệu trong trường hợp này. Bạn cần duyệt qua cây thư mục gốc và đếm số tệp bằng cách kết hợp lệnh find:

{ find / -xdev -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -k 1 -n | tail -n 20; }

Đối với các hệ thống có cấu trúc dữ liệu quá lớn khiến lệnh trên chạy chậm, bạn có thể kiểm tra từng cấp thư mục từ ngoài vào trong bằng đoạn script rút gọn sau:

for d in /*; do
  if [ -d "$d" ]; then
    echo -n "$d: "
    find "$d" -xdev 2>/dev/null | wc -l
  fi
done | sort -k 2 -n

Cột số hiển thị đầu tiên là tổng số tệp tin và thư mục con nằm trong đường dẫn đó. Khi đã định vị được thư mục gốc chứa hàng trăm nghìn hoặc hàng triệu đối tượng (ví dụ /var hoặc /tmp), bạn tiếp tục lặp lại thao tác đào sâu vào thư mục con (ví dụ /var/lib/...) để tìm ra nguồn phát sinh chính xác.

Cách xử lý tình trạng đầy inode theo từng nguyên nhân cụ thể

Việc giải phóng inode đòi hỏi thao tác xóa tệp trực tiếp. Tuy nhiên, khi một thư mục chứa từ vài trăm nghìn đến hàng triệu tệp, lệnh xóa thông thường như rm -rf * sẽ lập tức báo lỗi -bash: /bin/rm: Argument list too long do vượt quá giới hạn tham số của bộ thông dịch shell. Chúng ta phải sử dụng tiện ích find kết hợp cờ -delete để xóa an toàn theo từng khối luồng tệp tin.

1. PHP Session tích lũy quá nhiều tệp tạm

Đây là nguyên nhân phổ biến nhất trên các máy chủ chạy web application hoặc WordPress. Mặc định PHP lưu phiên đăng nhập của người dùng dưới dạng các tệp sess_* trong thư mục hệ thống.

Khi cơ chế thu gom rác (Garbage Collector – GC) của PHP bị lỗi cấu hình hoặc cronjob dọn dẹp mặc định trên Ubuntu bị tắt, các tệp này sẽ tích tụ theo thời gian và gây ra hiện tượng nghẽn chỉ mục, khiến lỗi 500 trên CyberPanel thường có liên quan đến tài nguyên hệ thống bùng phát hàng loạt.

Các vị trí lưu trữ session mặc định thường gặp:

• Ubuntu/Debian chuẩn: /var/lib/php/sessions/ hoặc /var/lib/php/session/
• CyberPanel / OpenLiteSpeed: /tmp/lshttpd/swap/ hoặc /var/lib/lsphp/session/
• CPanel / DirectAdmin: /tmp/

find /var/lib/php/sessions/ -type f -name "sess_*" -mtime +1 -delete

2. Hàng đợi thư điện tử Postfix Mail Queue bị tắc nghẽn

Khi website bị bot khai thác các form liên hệ chưa có captcha để spam thư rác hoặc mã độc cố gắng gửi hàng loạt email ra ngoài qua hàm mail() của PHP mà máy chủ chưa mở cổng SMTP, dịch vụ Postfix cục bộ sẽ giữ toàn bộ số thư thất bại này trong hàng đợi spool.

Hàng trăm nghìn thư kẹt trong thư mục /var/spool/postfix/maildrop/ hoặc /var/spool/postfix/deferred/ sẽ làm cạn kiệt inode chỉ sau vài ngày.

Việc thiết lập các giải pháp phòng thủ như bảo vệ form liên hệ khỏi spam bằng Cloudflare là giải pháp căn cơ để chặn đứng nguồn phát sinh này.

# Kiểm tra số lượng thư đang nghẽn trong hàng đợi Postfix
postqueue -p | tail -n 1

# Xóa toàn bộ hàng đợi thư rác bị kẹt
postsuper -d ALL

# Hoặc xóa trực tiếp trong thư mục spool nếu dịch vụ Postfix không phản hồi
find /var/spool/postfix/maildrop/ -type f -delete

3. Plugin bộ nhớ đệm WordPress sinh hàng triệu tệp nhỏ

Các plugin tạo cache phổ biến trên mã nguồn WordPress (như WP Super Cache, LiteSpeed Cache, W3 Total Cache) lưu trữ các phiên bản HTML tĩnh, CSS/JS nén thành vô số tệp nhỏ li ti trong thư mục wp-content/cache/.

Khi có bot hoặc công cụ quét URL với các tham số truy vấn liên tục thay đổi, plugin cache sẽ tạo mới tệp mà không kịp xóa tệp cũ, dẫn tới tình trạng cạn sạch tài nguyên phân vùng chỉ mục.

# Di chuyển đến thư mục website và xóa sạch bộ nhớ cache dạng file
cd /var/www/html/wp-content/cache/
find . -type f -delete

Sau khi dọn dẹp sạch sẽ khu vực lưu trữ tạm thời này, website của bạn sẽ thoát khỏi cảnh đóng băng dữ liệu, tạo điều kiện thuận lợi để website hoạt động bình thường trở lại trên VPS mà không còn bị chặn các tiến trình cập nhật cơ sở dữ liệu.

4. Nhật ký hệ thống và log ứng dụng không xoay vòng

Khi máy chủ xảy ra lỗi mã nguồn lặp đi lặp lại hoặc bị tấn công dò quét cổng, máy chủ web (Nginx, Apache) và các dịch vụ chạy nền sẽ ghi log liên tục với tốc độ chóng mặt.

Đồng thời, công cụ nhật ký systemd-journald trên Ubuntu có thể tạo ra hàng nghìn tệp journal phân mảnh. Trong quá trình rà soát, bạn cũng nên theo dõi tiến trình đang chạy bằng lệnh top để kiểm tra xem có tiến trình nào đang ghi đĩa quá mức hay không.

# Thu gọn dung lượng journalctl xuống mức tối đa 100MB
journalctl --vacuum-size=100M

# Làm rỗng nội dung log mà không xóa tệp (tránh lỗi ngắt file descriptor)
truncate -s 0 /var/log/nginx/access.log
truncate -s 0 /var/log/nginx/error.log

# Dọn dẹp cache gói cài đặt apt
apt-get clean
apt-get autoremove --purge -y

5. Phân tầng lưu trữ của Docker và tệp tạm cơ sở dữ liệu

Nếu VPS đang chạy Docker, cấu trúc hệ thống tệp tin overlay2 tại thư mục /var/lib/docker/overlay2/ sẽ tạo ra một lượng khổng lồ các lớp layer ảo và container tạm bị treo (dangling). Bạn cần kích hoạt lệnh dọn rác hệ thống chuyên dụng của Docker để giải phóng tài nguyên một cách an toàn:

docker system prune -af --volumes

Tương tự, nếu VPS đang chạy PostgreSQL hoặc MySQL, hãy kiểm tra các tệp tạm truy vấn phức tạp hoặc WAL logs bị treo trong /tmp và các phân vùng dữ liệu.

Đồng thời bạn có thể kiểm tra cổng dịch vụ đang mở với lệnh ss hoặc dùng netstat để rà soát kết nối đang hoạt động nhằm đảm bảo các tiến trình truy vấn mạng không bị treo đơ tạo ra tệp rác.

Xóa file xong mà inode vẫn không giảm: Nguyên nhân và cách xử lý

Một vấn đề rất hay gặp trong thực tế quản trị: bạn đã dùng lệnh find ... -delete và thư mục rác đã hoàn toàn trống rỗng, nhưng khi chạy lại lệnh df -ih thì chỉ số IUse% vẫn giữ nguyên ở mức 100%.

Nguyên nhân kỹ thuật: Nhân Linux (Linux Kernel) quy định rằng khi một tệp tin bị gỡ liên kết (unlink/delete) bởi người dùng nhưng vẫn đang có một tiến trình (process) nắm giữ bộ mô tả tệp mở (file descriptor), hệ điều hành sẽ chưa giải phóng cấu trúc inode đó về bảng chỉ mục trống.

Inode chỉ thực sự được hoàn trả khi tiến trình liên quan đóng luồng kết nối hoặc bị khởi động lại.

# Tìm danh sách các tiến trình đang giữ file đã bị xóa
lsof +L1
# Hoặc kiểm tra chi tiết theo từ khóa deleted
lsof | grep deleted

Kết quả hiển thị thường chỉ ra các tiến trình phổ biến như nginx, php-fpm, mysqld hoặc apache2. Để giải phóng ngay lập tức toàn bộ số lượng inode bị kẹt này, bạn chỉ cần khởi động lại dịch vụ tương ứng:

# Khởi động lại Web Server và PHP Process Manager
systemctl restart nginx
systemctl restart php8.2-fpm

# Kiểm tra lại bảng phân phối inode
df -ih

Các giải pháp phòng ngừa đầy inode tái diễn trên VPS Linux

Sau khi đã hoàn tất xử lý khẩn cấp, bạn cần thiết lập các chốt chặn kỹ thuật tự động để đảm bảo hệ thống không bao giờ bị nghẽn bảng chỉ mục trở lại.

1. Cấu hình Cronjob tự động dọn Session và Cache

Thiết lập lịch biểu chạy định kỳ vào ban đêm bằng crontab -e để máy chủ tự động quét và triệt tiêu các tệp phiên làm việc cũ không còn giá trị:

# Mở bảng quản lý lịch trình hệ thống
crontab -e

# Thêm tác vụ dọn session cũ hơn 24 giờ vào 3:00 sáng mỗi ngày
0 3 * * * find /var/lib/php/sessions/ -type f -name "sess_*" -mtime +1 -delete > /dev/null 2>&1

2. Chuẩn hóa cấu hình luân chuyển Log (Logrotate)

Đảm bảo các file nhật ký máy chủ web không bao giờ bị phân mảnh thành hàng nghìn tệp nhỏ. Kiểm tra tệp cấu hình /etc/logrotate.d/nginx để chắc chắn các chỉ số luân chuyển được định nghĩa chặt chẽ:

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
    endscript
}

3. Chuyển đổi cơ chế lưu Session PHP sang Redis hoặc Memcached

Cách triệt để nhất để không bao giờ phải bận tâm về inode do PHP tạo ra là chuyển toàn bộ session từ dạng tệp vật lý sang bộ nhớ RAM thông qua Redis Server. Trong tệp php.ini, bạn chỉ cần thay đổi 2 dòng tham số:

session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379"

4. Lựa chọn hệ thống tập tin: ext4 so với XFS

Khi khởi tạo máy chủ cho các ứng dụng có đặc thù sinh hàng chục triệu file nhỏ (như hệ thống lưu trữ cache ảnh, email server), cấu trúc định dạng đĩa đóng vai trò quyết định:

Đặc tính hệ thống tệp	Định dạng ext4 (Mặc định Ubuntu)	Định dạng XFS (Mặc định RHEL/CentOS)
Cơ chế cấp phát Inode	Cố định tại thời điểm tạo phân vùng (mkfs)	Động hoàn toàn (Dynamic Inode Allocation)
Nguy cơ đầy inode khi còn ổ cứng	Có thể xảy ra nếu nhiều file nhỏ	Rất hiếm khi xảy ra (Inode tăng tự động theo data)
Khả năng tăng inode sau cài đặt	Không thể tăng mà phải format lại toàn bộ	Tự động co giãn theo dung lượng đĩa trống

Câu hỏi thường gặp về tình trạng đầy inode trên Linux (FAQ)

1. Tại sao lệnh df -h vẫn báo còn dung lượng nhưng hệ thống lại không cho tạo tệp mới?

Bởi vì df -h chỉ thống kê dung lượng khối dữ liệu thực tế (GB), trong khi df -i theo dõi số lượng bản ghi chỉ mục siêu dữ liệu. Khi toàn bộ inode đã bị tiêu thụ hết bởi hàng triệu tệp nhỏ, Linux sẽ từ chối tạo thêm tệp mới và lập tức trả mã lỗi No space left on device.

2. Làm thế nào để biết phân vùng nào đang bị cạn kiệt inode?

Bạn chạy lệnh df -ih trên cửa sổ dòng lệnh SSH và nhìn vào cột IUse%. Bất kỳ phân vùng nào chạm mức 100% chính là phân vùng đang gặp sự cố. Trên phần lớn các máy chủ VPS tiêu chuẩn, phân vùng gốc / là nơi thường xuyên bị đầy nhất.

3. Sau khi xóa hàng triệu file bằng lệnh rm hoặc find, tại sao chỉ số inode vẫn không giảm?

Hiện tượng này xảy ra do một số tiến trình hệ thống (như Nginx hoặc PHP-FPM) vẫn đang giữ file descriptor mở với các tệp đó. Bạn dùng lệnh lsof | grep deleted để tìm định danh tiến trình liên quan rồi tiến hành khởi động lại dịch vụ tương ứng nhằm giải phóng hoàn toàn inode.

4. PHP session có phải là nguyên nhân phổ biến nhất gây cạn inode trên máy chủ web?

Chính xác. Trên các máy chủ vận hành WordPress hoặc web PHP có lượng truy cập lớn, việc cơ chế Garbage Collection của PHP không kích hoạt tự động sẽ khiến hàng triệu tệp sess_* tích tụ trong /var/lib/php/sessions/, làm đầy toàn bộ bảng inode chỉ sau vài ngày hoạt động.

5. Nên chọn hệ thống tệp ext4 hay XFS cho máy chủ lưu trữ nhiều file nhỏ?

XFS có cơ chế cấp phát inode động theo dung lượng thực tế, do đó xử lý các hệ thống chứa hàng chục triệu tệp tin nhỏ linh hoạt hơn ext4. Nếu bạn xây dựng hệ thống chuyên biệt về lưu trữ file, mail spool hoặc cache dữ liệu phân mảnh, định dạng XFS là lựa chọn tối ưu hơn.

Nội dung bài viết mang tính tham khảo. Các lệnh và cấu hình được kiểm chứng trên Ubuntu 22.04 LTS và Ubuntu 24.04 LTS với quyền root. Tùy phiên bản hệ điều hành, cấu hình VPS và môi trường thực tế, kết quả có thể khác. Người đọc nên sao lưu dữ liệu, kiểm thử trên môi trường staging và đánh giá rủi ro trước khi áp dụng cho hệ thống production.