Chốt ý nhanh

df -h
lsblk
mount | head
du -sh /var/log 2>/dev/null

sudo du -xh /var --max-depth=1 2>/dev/null | sort -h
sudo du -xh /var/log --max-depth=1 2>/dev/null | sort -h
sudo find /var/log -type f -size +100M -exec ls -lh {} \; 2>/dev/null

docker system df
docker images
docker ps -a

df -i

Kết bài

Disk full là kiểu sự cố rất hay gặp và thường gây áp lực lớn vì hệ thống có thể lỗi dây chuyền rất nhanh. Nếu anh nắm chắc bài này, anh sẽ biết cách xác định phân vùng đầy, tìm đúng thứ đang chiếm chỗ và xử lý có kiểm soát thay vì xóa theo cảm tính. Sang bài tiếp theo, anh sẽ học cách đọc log để hiểu hệ thống đang cố “nói gì” khi gặp trục trặc.

Phần thực hành mở rộng: disk và filesystem bằng các ca đầy ổ, mount và inode

Phần này rất nên thực hành vì lỗi disk là nhóm lỗi xảy ra thường xuyên trong production: đầy dung lượng, mount sai, inode hết, log phình to, backup ăn hết ổ.

Lab 1: Chụp nhanh tình trạng disk

df -h
lsblk
mount | head -20

Mục tiêu là biết:

• máy có những block device nào
• chúng đang mount ở đâu
• phân vùng nào đang gần đầy

Lab 2: Tìm thư mục nào đang chiếm chỗ

sudo du -sh /var/* 2>/dev/null | sort -h | tail -20
sudo du -sh /home/* 2>/dev/null | sort -h

Khi thấy ổ đầy, đừng đoán. Hãy đo bằng du. Đây là phản xạ rất quan trọng.

Lab 3: Mô phỏng file lớn

mkdir -p /tmp/disk-lab
fallocate -l 500M /tmp/disk-lab/bigfile.img
df -h /tmp
du -sh /tmp/disk-lab
rm -f /tmp/disk-lab/bigfile.img

Nếu fallocate không có, thử:

dd if=/dev/zero of=/tmp/disk-lab/bigfile.img bs=1M count=500

Bài này giúp người mới thấy rõ dung lượng thay đổi ra sao.

Lab 4: inode có thể đầy dù còn dung lượng

df -i
mkdir -p /tmp/inode-lab
for i in $(seq 1 5000); do touch /tmp/inode-lab/file-$i; done
find /tmp/inode-lab | wc -l
df -i /tmp
rm -rf /tmp/inode-lab

Nhiều người chỉ nhìn df -h mà quên df -i. Một thư mục có quá nhiều file nhỏ có thể làm hết inode trước khi đầy GB.

Lab 5: /etc/fstab và rủi ro mount sai

Không cần chỉnh bừa trên production. Chỉ cần đọc và hiểu:

cat /etc/fstab
lsblk -f
blkid | head

Hãy đối chiếu UUID, filesystem type và mountpoint. Một dòng sai trong /etc/fstab có thể khiến máy boot lỗi.

Lab 6: Tìm file đang bị xóa nhưng process vẫn giữ

Khi log file bị xóa mà disk chưa giảm, có thể process vẫn đang mở file:

sudo lsof +L1 | head -20

Đây là kỹ năng rất thực chiến, đặc biệt với log web/app.

Tình huống thực tế

Website báo lỗi không upload được ảnh. Kiểm tra đúng thứ tự thường là:

1. df -h
2. df -i
3. du -sh thư mục liên quan
4. quyền thư mục upload
5. log ứng dụng hoặc web server

Lỗi phổ biến

• Chỉ biết df -h mà không biết du.
• Xóa file log nhưng disk không giảm vì process còn giữ file.
• Không kiểm tra inode.
• Sửa /etc/fstab mà không test cẩn thận.

Bài tập thêm

1. Tạo file lớn 200-500 MB và quan sát df, du.
2. Tạo hàng nghìn file nhỏ và so sánh df -h với df -i.
3. Viết checklist xử lý disk full dài 6 bước.

Phần đào sâu thêm: xử lý disk full như một ca sự cố thật

Disk full là lỗi rất “đời thường” nhưng gây downtime cực nhanh: database không ghi được, web không upload được, log không xoay được, backup thất bại.

Runbook ngắn khi nghi máy đầy ổ

1. df -h xem phân vùng nào đầy
2. df -i xem có hết inode không
3. du -sh tìm thư mục phình to
4. lsof +L1 kiểm tra file đã xóa nhưng còn bị giữ
5. Xác nhận nguyên nhân trước khi xóa dữ liệu

Lab bổ sung: tìm top thư mục chiếm chỗ

sudo du -xhd1 / | sort -h
sudo du -xhd1 /var | sort -h

Thói quen dùng -x giúp anh chỉ nhìn trong cùng filesystem, tránh nhiễu khi máy có nhiều mountpoint.

Tình huống thực tế hơn

Nhiều ca disk full không đến từ dữ liệu ứng dụng, mà từ log rotate lỗi, core dump, backup cũ, Docker image cũ hoặc file tạm không được dọn. Vì vậy phải đo rồi mới kết luận.

Phần thực hành nâng cao: xử lý disk full và đọc filesystem như người vận hành production

Nếu phần trước giúp anh biết các lệnh cơ bản như df và du, thì phần này sẽ đẩy tư duy lên gần hơn với môi trường thật. Trong production, sự cố disk không chỉ là “ổ đầy”, mà thường kéo theo database lỗi ghi, web server treo, log không ghi thêm được, backup fail và cả monitoring bắn alert dây chuyền. Người học cần biết cách điều tra có thứ tự, dọn dẹp có kiểm soát và tránh những cú xóa nhầm rất đắt giá.

Lab 7: Phân biệt block device, partition, filesystem và mount point

lsblk
lsblk -f
blkid
mount | column -t | head -30

Người mới rất hay lẫn các khái niệm này với nhau. Anh nên buộc người học tự giải thích bằng lời:

• block device là thiết bị lưu trữ nhìn từ hệ điều hành, ví dụ /dev/sda hoặc /dev/vda
• partition là phần chia ra từ device, ví dụ /dev/sda1
• filesystem là cách dữ liệu được tổ chức, ví dụ ext4, xfs
• mount point là nơi filesystem được gắn vào cây thư mục, ví dụ /, /var, /data

Nếu không phân biệt lớp nào là lớp nào, người học rất dễ resize sai, format nhầm hoặc điều tra nhầm phân vùng.

Lab 8: Đọc df đúng cách thay vì chỉ nhìn phần trăm

df -h
df -Th
df -i

Giải thích cho người học ba góc nhìn khác nhau:

• df -h cho biết dung lượng đã dùng/còn trống theo block
• df -Th thêm loại filesystem, rất hữu ích khi phân tích ext4, xfs, tmpfs
• df -i cho biết inode, cực quan trọng vì có lúc còn nhiều GB trống nhưng vẫn không tạo được file mới do hết inode

Bài tập: ghi ra 2 tình huống khác nhau — một máy đầy block và một máy đầy inode — rồi mô tả dấu hiệu bề ngoài của từng ca.

Lab 9: Dùng du để truy nguồn thư mục nào đang phình to

sudo du -xh /var | sort -h | tail -20
sudo du -xh /home | sort -h | tail -20
sudo du -xhd1 / | sort -h

Nhấn mạnh cho người học:

• du trả lời câu hỏi “thư mục nào đang chiếm chỗ”
• df trả lời câu hỏi “filesystem nào đang đầy”
• đừng nhầm hai công cụ này vì chúng phục vụ hai lớp điều tra khác nhau

-x giúp không đi lạc sang filesystem khác; -d1 giúp nhìn theo từng tầng, rất hợp để khoanh vùng nhanh.

Lab 10: Tạo file lớn rồi tự điều tra lại bằng df và du

fallocate -l 1G /tmp/lab-bigfile.img
ls -lh /tmp/lab-bigfile.img
df -h /tmp
du -sh /tmp/* 2>/dev/null | sort -h | tail

Sau đó xóa file:

rm -f /tmp/lab-bigfile.img
df -h /tmp

Lab này rất đơn giản nhưng hiệu quả. Người học sẽ thấy tận mắt dung lượng thay đổi như thế nào, và hiểu rằng phải đối chiếu cả df lẫn du thay vì chỉ tin một lệnh.

Lab 11: Mô phỏng tình huống file đã xóa nhưng disk vẫn chưa giảm

Đây là một case production kinh điển: process vẫn giữ file descriptor của file log cũ dù file đã bị xóa khỏi thư mục.

tail -f /var/log/syslog >/tmp/hold-fd.txt &
lsof +L1 | head -20

Hoặc trên máy lab riêng, anh có thể tạo một file, mở nó bằng process nền rồi xóa file đó. Điều người học cần nhớ là:

• du có thể không còn thấy file
• nhưng df vẫn báo đầy vì process còn giữ inode/file descriptor
• lsof +L1 thường là lệnh cứu mạng trong những ca “xóa rồi mà disk không nhả”

Sau khi xác định process giữ file, anh mới cân nhắc restart đúng service hoặc logrotate đúng cách.

Lab 12: Kiểm tra inode cạn kiệt bằng cách tạo nhiều file nhỏ

mkdir -p /tmp/inode-lab
for i in $(seq 1 20000); do touch /tmp/inode-lab/file_$i; done
df -i /tmp
find /tmp/inode-lab | wc -l

Sau lab thì dọn dẹp:

rm -rf /tmp/inode-lab
df -i /tmp

Không phải máy nào cũng đủ điều kiện để tái hiện rõ hiệu ứng hết inode, nhưng chỉ riêng việc cho người học thấy khái niệm này tồn tại đã rất đáng giá. Rất nhiều bạn mới đi làm chỉ biết “còn GB trống” mà không hề nghĩ đến inode.

Lab 13: Tìm log, backup, cache và artifact build đang ăn disk

sudo du -xhd1 /var/log | sort -h
sudo du -xhd1 /var/cache | sort -h
sudo du -xhd1 /tmp | sort -h
sudo du -xhd1 /home | sort -h

Cho người học quen với các thủ phạm phổ biến:

• log phình to do lỗi lặp liên tục
• backup giữ quá nhiều bản cũ
• cache package manager hoặc container image không dọn
• artifact build, file upload hoặc dump tạm bị quên

Mục tiêu là hình thành phản xạ khoanh vùng nguyên nhân trước, dọn dẹp sau.

Lab 14: Kiểm tra không gian dành riêng của root trên ext filesystem

sudo tune2fs -l /dev/sda1 | egrep 'Block count|Reserved block count|Reserved block percentage' 

Tùy máy lab mà device sẽ khác. Không cần bắt người học nhớ hết ngay, nhưng nên giải thích rằng trên một số filesystem Linux có phần block dự phòng cho root. Vì vậy đôi khi người dùng thường thấy “hết chỗ” nhưng root vẫn còn khả năng thao tác tối thiểu để cứu hệ thống.

Lab 15: Quan sát mount options và fstab để hiểu hệ thống sẽ mount ra sao sau reboot

cat /etc/fstab
findmnt
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS

Đây là chỗ kết nối từ việc “đọc trạng thái hiện tại” sang “hiểu cấu hình tồn tại lâu dài”. Người học nên biết:

• mount hiện tại có thể do boot, do tay người vận hành, hoặc do systemd tự mount
• sửa mount tạm thời khác hoàn toàn với sửa /etc/fstab
• một lỗi trong fstab có thể khiến máy boot lỗi hoặc vào emergency mode

Lab 16: Checklist điều tra chuẩn khi nhận alert disk usage cao

1. Xác định filesystem nào đầy bằng df -h và df -i.
2. Nếu là block usage cao, dùng du khoanh thư mục lớn nhất trong đúng filesystem đó.
3. Nếu du không giải thích được chênh lệch, kiểm tra lsof +L1 để tìm file đã xóa nhưng còn bị giữ.
4. Xác định dữ liệu đó thuộc loại gì: log, backup, cache, upload, database, image container hay dump tạm.
5. Chỉ sau khi hiểu rõ mới chọn cách xử lý: xóa, rotate, nén, chuyển nơi lưu, tăng disk hoặc chỉnh retention.

Checklist này nên được học thuộc theo kiểu tư duy, không phải kiểu học vẹt câu lệnh.

Tình huống thực tế 1: /var đầy làm cả web app lẫn database cùng lỗi

Một máy dùng chung phân vùng /var cho log ứng dụng, log hệ thống và data của một số dịch vụ phụ. Một bug khiến log ứng dụng tăng hàng chục GB chỉ trong vài giờ. Kết quả là không chỉ web app lỗi ghi log, mà cả database cũng bắt đầu báo lỗi tạm vì thiếu chỗ ghi file tạm. Nếu chỉ restart web service mà không xử lý nguyên nhân chiếm disk, sự cố sẽ quay lại gần như ngay lập tức.

Tình huống thực tế 2: File log đã bị xóa nhưng dung lượng không giảm

Người vận hành thấy /var/log/app.log lớn 20GB nên xóa ngay. Sau đó ls không còn file, nhưng df -h vẫn gần 100%. Hóa ra process ứng dụng vẫn đang giữ file descriptor cũ. Đây là lúc lsof +L1 phát huy tác dụng, và cách xử lý đúng thường là reload/restart service có kiểm soát hoặc cấu hình logrotate chuẩn hơn.

Tình huống thực tế 3: Hết inode vì hàng triệu file cache nhỏ

Một service sinh rất nhiều thumbnail hoặc file cache nhỏ. Tổng dung lượng chưa tới vài GB, nhưng số file quá lớn làm inode cạn trước. Người mới nhìn df -h thấy vẫn còn trống nên đi tìm “file to” mãi không ra, trong khi df -i mới là chìa khóa của bài toán.

Lỗi phổ biến khi học phần này

• Chỉ chạy df -h rồi kết luận ngay mà không kiểm tra inode.
• Dùng du ở sai mount point nên số liệu bị lệch.
• Xóa bừa log, backup hoặc dữ liệu ứng dụng khi chưa xác định chủ sở hữu và giá trị của chúng.
• Không biết đến trường hợp file đã xóa nhưng process còn giữ.
• Nhìn thấy phân vùng đầy là nghĩ ngay phải tăng disk, trong khi nguyên nhân thật là retention/logrotate tệ.

Bài tập thực hành cuối bài

1. Dùng lsblk, df -Th và findmnt để mô tả sơ đồ lưu trữ của máy lab.
2. Tạo một file lớn trong /tmp, quan sát thay đổi bằng df và du, rồi dọn lại.
3. Tạo nhiều file nhỏ để quan sát khái niệm inode.
4. Viết một runbook ngắn: “Nếu nhận alert disk usage 95%, em sẽ kiểm tra theo thứ tự nào?”.
5. Nêu ít nhất 3 nguyên nhân production thực tế có thể làm disk tăng nhanh ngoài dự kiến.

Kết bài

Nếu làm chắc phần này, anh sẽ có một phản xạ rất đáng tiền trong vận hành: không hoảng khi thấy disk gần đầy, mà biết phải nhìn đúng lớp thông tin, khoanh vùng đúng chỗ và xử lý theo mức độ an toàn phù hợp. Đây là kỹ năng cực hay dùng vì sự cố lưu trữ xuất hiện ở gần như mọi hệ thống, từ VPS nhỏ đến production nhiều dịch vụ.