Filesystem Troubleshooting

Filesystem yang sakit jarang mengumumkan dirinya lewat satu pesan besar; yang muncul justru gejala-gejala kecil yang tampak tidak berhubungan: penulisan file gagal tanpa alasan jelas, aplikasi error di tengah pekerjaan, atau df yang tetap melaporkan penuh beberapa hari setelah file raksasa dihapus. Di balik semuanya ada pola yang bisa didiagnosis — dan hampir semuanya bermuara ke empat penyebab: filesystem dikunci read-only oleh kernel, struktur metadata rusak, inode habis, atau file yang sudah dihapus masih dipegang proses. Chapter penutup Section ini merangkai gejala, diagnosis, dan perintahnya menjadi satu prosedur yang bisa diulang.

Filesystem yang Mendadak Read-Only #

Saat kernel mendeteksi metadata yang tidak konsisten — akibat mati listrik di tengah penulisan, atau sektor disk yang mulai gagal — ia mengambil keputusan tegas: merombak filesystem menjadi read-only demi mencegah kerusakan meluas. Semua penulisan berikutnya ditolak dengan pesan Read-only file system, dan tidak sedikit pun data baru bisa masuk sampai masalahnya diperbaiki. Pesan ini perlu dibedakan dari penolakan karena izin — keduanya sama-sama membuat echo gagal, tetapi akar masalahnya berbeda:

mkdir -p latihan
cd latihan
printf 'isi penting\n' > berkas.log
chmod 444 berkas.log
(echo "baris baru" >> berkas.log) 2>&1
(echo "baris baru" > /proc/sys/net/ipv4/ip_forward) 2>&1

Output yang Dihasilkan:

bash: berkas.log: Permission denied
bash: /proc/sys/net/ipv4/ip_forward: Read-only file system

Dua baris keluaran di atas adalah dua dunia yang berbeda. Baris pertama (Permission denied) muncul karena permission file: pemiliknya sendiri menutup bit write lewat chmod 444, sehingga user biasa ditolak — tetapi root masih bisa menulis. Baris kedua (Read-only file system) dipancing dari procfs yang memang dipasang read-only di lingkungan latihan ini: penolakannya datang dari lapisan filesystem itu sendiri, dan tidak ada user mana pun — root termasuk — yang bisa menulis sampai filesystem dilepas dan diperbaiki. Tanda kurung di sekeliling kedua echo sengaja dipasang: penolakan terjadi di tahap redirection yang dikerjakan shell, jadi 2>&1 harus menempel pada subshell agar pesannya ikut tertangkap. Dengan begini, saat sebuah server tiba-tiba menolak semua penulisan padahal ls -l tampak normal, dugaan pertama bukan permission, melainkan remount read-only oleh kernel.

Jalur perbaikannya selalu berurutan: lepaskan filesystem (umount), perbaiki strukturnya, pasang kembali. Untuk filesystem root yang tidak bisa dilepas, perbaikan dilakukan dari mode recovery saat boot atau dari live USB.

fsck: Memeriksa dan Memperbaiki #

fsck (filesystem check) adalah pemeriksa dan penyetrum metadata: ia menelusuri tabel inode, peta blok, dan struktur direktori, lalu memperbaiki ketidakcocokan yang ditemukan. Berikut contoh tampilan ujiannya pada partisi yang jurnalnya pernah terputus:

$ sudo fsck -y /dev/sdb1
fsck from util-linux 2.41
e2fsck 1.47.2 (14-Jan-2024)
/dev/sdb1: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Free blocks count wrong for group #0 (12345, counted=12300). Fix? yes

/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****

Opsi -y menjawab yes untuk semua pertanyaan perbaikan — tanpa opsi ini, fsck bertanya satu per satu dan pertanyaannya sulit dijawab tanpa pemahaman mendalam. Baris recovering journal memperlihatkan jurnal ext4 bekerja: transaksi yang belum selesai diputar ulang lebih dulu sebelum pemeriksaan penuh dimulai.

Kasus terparah yang bisa ditangani tanpa format ulang adalah superblock rusak — blok pertama berisi peta induk seluruh struktur. mkfs.ext4 diam-diam menyimpan salinan superblock di beberapa lokasi cadangan, sehingga perbaikan dilakukan dengan sudo e2fsck -b 32768 /dev/sdb1: membaca salinan di blok 32768 lalu menulis ulang salinan yang rusak.

Inode Habis: Menulis Gagal Padahal Ruang Longgar #

Penyakit favorit direktori cache dan folder email: df -h menunjukkan puluhan persen ruang kosong, tetapi touch berkas-baru ditolak dengan No space left on device. Setiap file menghabiskan tepat satu inode terlepas dari ukurannya, dan kuota inode ditetapkan tetap saat mkfs — jutaan file kecil bisa menghabiskannya seluruhnya sementara total byte-nya belum satu gigabyte. Diagnosisnya satu perintah: df -i, dan tanda tangannya kolom IUse% yang menunjuk 100% (dengan IFree nol) sementara df -h masih longgar. Penanganannya: temukan direktori dengan jumlah file terbanyak, misalnya for d in /var/*/; do echo "$(ls -1 "$d" | wc -l) $d"; done | sort -rn | head, lalu kosongkan bersama aplikasi pemiliknya.

File Dihapus tetapi Ruang Tidak Kembali #

Skenario paling membingungkan: file log raksasa sudah rm, ls tidak menemukannya lagi, tetapi df masih melaporkan penuh persis seperti semula. Linux tidak membebaskan blok file selama masih ada proses yang memegangnya — dan rm hanya menghapus nama, bukan pegangannya. Pola khasnya: aplikasi server membuka file log, administrator menghapus file itu dari bawahnya, dan ruang tidak pernah kembali sampai aplikasi di-restart. Perintah sudo lsof +L1 | sort -k7 -rn mendaftar file dengan link count di bawah satu yang masih dipegang proses — tersangka utamanya selalu baris paling atas. Solusinya me-restart service pemegangnya; simulasi mekanismenya dibedah langsung di Chapter Disk Space Problems , dan pemantauan rutinnya di Disk Monitoring .

Jejak di Log Kernel: dmesg #

Kernel tidak diam saat disk mulai gagal: setiap kejadian I/O tercatat di log kernel yang bisa dibaca lewat dmesg atau journalctl -k. Karena keluaran aslinya panjang dan berbeda-beda antar mesin, kita saring potongan yang relevan dari fixture:

mkdir -p latihan
cd latihan
cat > dmesg-potongan.txt << 'EOF'
[    0.000000] Linux version 6.1.0-13-amd64 ([email protected])
[ 1234.567890] sd 0:0:0:0: [sdb] tag#12 FAILED Result: hostbyte=DID_OK
[ 1234.567901] sd 0:0:0:0: [sdb] tag#12 CDB: Read(10) 00 00 00 00
[ 1234.570000] EXT4-fs error (device sdb1): ext4_find_entry:1455: inode #1027
[ 1234.580000] Aborting journal on device sdb1-8
[ 1234.590000] EXT4-fs (sdb1): Remounting filesystem read-only
EOF
grep -E 'FAILED|EXT4-fs|Aborting' dmesg-potongan.txt

Output yang Dihasilkan:

[ 1234.567890] sd 0:0:0:0: [sdb] tag#12 FAILED Result: hostbyte=DID_OK
[ 1234.570000] EXT4-fs error (device sdb1): ext4_find_entry:1455: inode #1027
[ 1234.580000] Aborting journal on device sdb1-8
[ 1234.590000] EXT4-fs (sdb1): Remounting filesystem read-only

Empat baris hasil saringan itu adalah kronologi lengkap sebuah kejadian: perintah baca ke disk sdb gagal (FAILED), error itu sampai ke lapisan ext4, jurnal dibatalkan demi keamanan (Aborting journal), dan kernel mengunci filesystem menjadi read-only. Di mesin nyata, pola grep yang sama dijalankan langsung: dmesg | grep -E 'I/O error|EXT4-fs error'. Bila baris-baris ini terus bertambah setiap jam, masalahnya ada di perangkat kerasnya — kesehatan fisik disk dibahas tuntas di Chapter Disk Health Monitoring .

Peta Cepat: Gejala, Diagnosis, Perintah #

Skrip Cek Kesehatan Dua Indikator #

Empat penyebab tadi bermuara ke dua indikator yang bisa diperiksa tanpa alat khusus: persentase ruang dan persentase inode. Skrip berikut memilah keduanya dari dua laporan yang tersimpan sebagai fixture — pola yang tinggal mengganti file dengan keluaran df -h dan df -i sungguhan:

mkdir -p latihan
cd latihan
cat > df-h.txt << 'EOF'
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        40G   32G  5.2G  87% /
/dev/sdb1       100G   96G     0 100% /mnt/backup
EOF
cat > df-i.txt << 'EOF'
Filesystem      Inodes  IUsed  IFree IUse% Mounted on
/dev/sda1      2621440 786432 1835008   30% /
/dev/sdb1        65536   7864   57672   12% /mnt/backup
EOF
echo "== ruang =="
awk 'NR > 1 { s = $5; sub(/%/, "", s); if (s + 0 >= 85) print $6 " " s "%" }' df-h.txt
echo "== inode =="
awk 'NR > 1 { s = $5; sub(/%/, "", s); if (s + 0 >= 85) print $6 " " s "%" }' df-i.txt

Output yang Dihasilkan:

== ruang ==
/ 87%
/mnt/backup 100%
== inode ==

Mari kita telaah isi skrip di atas:

1. Baris 3–7 (cat > df-h.txt): snapshot pemakaian ruang blok dari df -h, disimpan sebagai fixture agar bisa diulang.
2. Baris 8–12 (cat > df-i.txt): snapshot pemakaian inode dari df -i, untuk pasangan filesystem yang sama.
3. Baris 13–14 (echo + awk): memilah indikator ruang — NR > 1 melewati baris judul, sub(/%/, "", s) mengupas tanda persen agar kolom bisa dibandingkan sebagai angka, dan s + 0 >= 85 menandai yang melewati ambang 85%.
4. Baris 15–16: filter yang persis sama untuk indikator inode — satu pola dipakai dua kali karena struktur kolom kedua laporan identik.

Hasilnya memisahkan dua diagnosis dalam sekali jalan: /mnt/backup melewati ambang pada indikator ruang (100%) tetapi sehat pada indikator inode (12%), jadi penyakitnya pasti file-file besar — bukan jutaan file kecil; sementara / berada di 87% ruang, cukup untuk masuk daftar pantauan. Bagian == inode == yang kosong justru informatif: tidak ada satu pun filesystem yang kehabisan entri. Di mesin produksi, skrip seperti ini cukup dibungkus cron atau systemd timer untuk menjadi alarm dini — pembungkusan lengkapnya dibahas di Section Process dan Jobs.

Dengan ini peta filesystem kita lengkap: struktur pohon, path, link, mount, partisi, jenis filesystem, ukuran, arsip — sampai cara menyembuhkannya. Semua itu adalah benda mati yang menunggu dikerjakan; yang menggerakkan semuanya adalah shell. Perjalanan berikutnya dimulai dari Section Shell dan Scripting .

Referensi lanjut: fsck(8) dan dmesg(1) untuk opsi lengkap kedua alat diagnosis.