WIKI TKJ

Linux : Praktikum Mount, fsck, dan Perluasan Filesystem

Revision as of 16:02, 5 November 2026 by Maintenance script (talk | contribs) (Protected "Linux : Praktikum Mount, fsck, dan Perluasan Filesystem": Proteksi editorial: edit/move sysop ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Disk yang penuh belum tentu kecil, dan mount yang gagal belum tentu rusak. Saat server mengeluh, yang rusak biasanya cuma satu lapis — dan tugasmu adalah menunjuk lapis mana, dengan satu perintah dan satu angka, bukan menebak.

Artikel ini adalah lanjutan langsung dari konsep empat lapis di Linux : Disk, Partisi, dan Filesystem (Mount dan fstab). Pagi tadi kamu belajar bahwa disk, partisi, filesystem, dan mount adalah empat lapis satu arah. Sore ini kamu akan membangun keempatnya di atas satu file image, lalu mematahkannya satu per satu dengan sengaja.

🎯 Tujuan

Setelah menyelesaikan praktikum ini, kamu bisa:

  • Membangun disk uji dari file image dan loop device, tanpa menyentuh disk asli server.
  • Mengumpulkan bukti untuk keempat lapis: perangkat, partisi, filesystem, dan mount.
  • Membedakan penuh karena blok dengan penuh karena inode — dua gejala yang mirip, obatnya beda.
  • Menemukan proses yang menahan umount dan tahu kenapa umount -l berbahaya.
  • Menjalankan e2fsck dengan aman dan membaca hasilnya.
  • Memperluas filesystem dengan urutan yang benar: partisi dulu, filesystem kemudian.
  • Menguji entri fstab tanpa reboot dan tanpa risiko masuk emergency mode.

📍 Konteks nyata

Bayangkan kamu membawa motor ke bengkel karena mesinnya mati. Tukang yang buruk langsung membongkar mesin. Tukang yang baik mengecek dulu: bensin ada? busi nyala? filter kotor?

Diagnosa disk bekerja dengan urutan yang sama. Kamu tidak memformat ulang disk hanya karena aplikasi bilang "No space left on device". Kamu cek satu per satu dari lapis paling bawah.

🔥 Kasus nyata: Sebuah SMK memakai satu server untuk ujian berbasis komputer. Pagi hari ujian, aplikasi menolak menyimpan jawaban dengan pesan "No space left on device". Panitia cek df -h, ternyata disk masih 46 persen. Karena bingung, dua hard disk baru dibeli dan dipasang. Ujian tertunda dua hari. Penyebab aslinya: folder session PHP berisi 1,2 juta file kecil, jadi inode habis sementara ruang masih lega. Satu perintah df -i akan menunjukkan masalahnya dalam lima detik.

🧠 Konsep singkat

Empat lapis itu punya pertanyaan berbeda. Kalau kamu bertanya hal yang salah ke lapis yang salah, jawabannya selalu menyesatkan.

Lapis Pertanyaan Bukti Gejala kalau salah
Disk Perangkatnya terdeteksi? lsblk, dmesg perangkat tidak muncul sama sekali
Partisi Batasnya sudah benar? lsblk, parted print ruang ada, tapi tidak terpakai
Filesystem Isinya sehat dan ada slot? blkid, df -h, df -i "No space left" walau lega
Mount Menempel di jalur yang benar? findmnt file menumpuk di direktori kosong

Aturan kerjanya cuma satu: berhenti di lapis pertama yang gagal. Kalau perangkat tidak terdeteksi, jangan urus fstab. Kalau partisi belum diperbesar, jangan jalankan resize2fs. Melompat lapis adalah cara paling cepat menghabiskan waktu.

🔹 Penuh karena blok, penuh karena inode

Setiap file butuh dua hal: ruang data (blok) dan satu slot catatan (inode). Satu file video 2 GB memakai satu inode. Sepuluh ribu file log 1 KB juga memakai sepuluh ribu inode.

Karena itu ada dua jenis "penuh". Penuh blok terlihat di df -h. Penuh inode hanya terlihat di df -i. Pesan errornya sama persis, jadi kamu harus memeriksa keduanya.

📊 Angka penting: Default ext4 menyediakan satu inode untuk setiap 16 KiB ruang. Disk 100 GB berarti sekitar 6,5 juta inode. Kedengarannya banyak, sampai ada folder session atau cache yang membuat ratusan ribu file kecil.

🔹 fsck bukan obat segala penyakit

ext4 memakai journal. Setelah listrik padam, e2fsck biasanya hanya memutar ulang journal lalu keluar — bukan memeriksa seluruh disk. Pemeriksaan penuh baru terjadi kalau superblock menandai filesystem belum bersih.

⚠️ Hati-hati: Manual e2fsck(8) menulis tegas bahwa memeriksa filesystem yang sedang ter-mount tidak aman. Satu-satunya pengecualian adalah opsi -n (baca saja), dan bahkan hasilnya tidak valid. Kalau e2fsck bertanya apakah filesystem ter-mount perlu diperiksa, jawaban yang benar adalah tidak.

🔹 Memperluas itu dua langkah, bukan satu

Ini jebakan paling sering. Kamu menambah ukuran disk di Proxmox, lalu menjalankan resize2fs, dan hasilnya "Nothing to do!".

Manual resize2fs(8) menjelaskan sebabnya: perintah itu tidak mengubah ukuran partisi. Filesystem tidak boleh lebih besar dari partisinya. Jadi urutannya selalu: perbesar partisi, baru perbesar filesystem.

🧩 Istilah penting

Istilah Arti sederhana
Loop device File biasa yang dipakai seolah-olah hard disk, misalnya /dev/loop0
Superblock Catatan induk filesystem: ukuran, status bersih/kotor, jumlah mount
Inode Slot catatan untuk satu nama file; bukan isi filenya
Journal Catatan sementara perubahan, supaya pemulihan setelah mati listrik cepat
Dirty Status filesystem yang belum ditutup dengan rapi
fsck pass Tahap pemeriksaan; angka di kolom keenam fstab
Mount unit Nama unit systemd untuk satu mount, misalnya mnt-lab.mount
Lazy umount Melepas mount dari pohon direktori, tapi proses lama tetap memakai filesystem

🔧 Praktik: Membangun, Merusak, dan Membuktikan Lapis Disk

Semua langkah di bawah memakai file image, bukan partisi asli. Aman diulang, aman salah, dan tidak bisa menghapus data server.

⚠️ Hati-hati: Jangan pernah menjalankan mkfs, parted, atau resize2fs di server produksi sebagai latihan. Salah satu huruf di nama device bisa menghapus data yang tidak bisa dikembalikan.

🔹 Langkah 0: Siapkan tempat latihan

Gunakan VM Debian, atau server lab yang memang boleh dirusak. Pastikan kamu punya akses root. 

sudo -i
mkdir -p /srv/lab-disk
cd /srv/lab-disk
fallocate -l 1G disk-lab.img
losetup -fP --show disk-lab.img

Perintah terakhir mencetak nama loop device, misalnya /dev/loop0. Di catatan ini kita anggap hasilnya /dev/loop0 — sesuaikan dengan punyamu.

📊 Angka penting: fallocate memesan ruang tanpa menulis nol ke seluruh file, jadi 1 GiB selesai dalam hitungan milidetik, bukan menit.

🔹 Langkah 1: Buat partisi, filesystem, dan mount point

Kita sengaja memakai partisi 700 MiB di dalam disk 1 GiB. Sisa 300 MiB itulah yang nanti dipakai untuk uji perluasan. 

parted -s /dev/loop0 mklabel gpt
parted -s /dev/loop0 mkpart primary ext4 1MiB 701MiB
partx -u /dev/loop0
lsblk /dev/loop0

mkfs.ext4 -L LABDISK /dev/loop0p1
mkdir -p /mnt/lab
mount /dev/loop0p1 /mnt/lab

Kalau /dev/loop0p1 belum ada setelah parted, jalankan partx -u /dev/loop0 lagi. Kernel perlu diberi tahu bahwa tabel partisi berubah — membuat partisi tidak otomatis membuka device-nya.

🔹 Langkah 2: Kumpulkan bukti keempat lapis

Ini baseline kamu. Catat hasilnya, karena nanti kita akan membandingkan. 

lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINTS /dev/loop0
blkid /dev/loop0p1
findmnt /mnt/lab
df -h /mnt/lab
df -i /mnt/lab

Yang harus kamu lihat: disk 1G, partisi 700M, filesystem ext4 berlabel LABDISK, dan mount point /mnt/lab. Empat baris bukti, empat lapis.

🧪 Uji cepat: findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /mnt/lab menjawab lapis mount dalam satu baris, lebih ringkas daripada membaca mount yang panjang.

🔹 Langkah 3: Uji A — penuh karena blok

dd if=/dev/zero of=/mnt/lab/penuh.bin bs=1M status=progress
df -h /mnt/lab
ls -lh /mnt/lab/penuh.bin

dd akan berhenti dengan pesan "No space left on device". Perhatikan df -h: Use% mencapai 100 persen, tapi Available menunjukkan angka kecil atau nol.

📊 Angka penting: ext4 menyisihkan 5 persen blok khusus root. Di partisi 700 MiB itu sekitar 35 MiB. Artinya user biasa sudah ditolak, sementara root masih bisa menulis sedikit — dan itu sering membuat gejala terlihat tidak konsisten.

Hapus lagi file uji sebelum lanjut: 

rm /mnt/lab/penuh.bin
df -h /mnt/lab

🔹 Langkah 4: Uji B — penuh karena inode

Sekarang kita isi partisi yang sama dengan file kosong berukuran nol byte. 

mkdir -p /mnt/lab/kecil
cd /mnt/lab/kecil
i=0
while : > "f$i" 2>/dev/null; do i=$((i+1)); done
echo "berhasil membuat $i file"
df -h /mnt/lab
df -i /mnt/lab

Hasil yang diharapkan: df -h menunjukkan pemakaian sangat kecil, tapi df -i menunjukkan IUse% 100 persen. Coba buat satu file baru — gagal, padahal ruang masih banyak.

Inilah pelajaran intinya: "No space left on device" adalah pesan tentang slot, bukan hanya tentang ukuran. Kalau kamu hanya melihat df -h, kamu akan membeli disk baru tanpa perlu.

Bersihkan: 

cd /
rm -rf /mnt/lab/kecil
df -i /mnt/lab

🔹 Langkah 5: Uji C — umount gagal karena "target is busy"

Buka satu terminal, masuk ke dalam mount point, lalu biarkan di sana. 

cd /mnt/lab

Di terminal kedua: 

umount /mnt/lab
lsof /mnt/lab
fuser -vm /mnt/lab

umount menolak dengan "target is busy". fuser -vm menampilkan PID, user, dan jenis akses; huruf c berarti proses itu sedang menjadikan direktori tersebut sebagai working directory. Setelah terminal pertama keluar dari /mnt/lab, umount langsung berhasil.

⚠️ Hati-hati: umount -l (lazy) terlihat seperti solusi karena perintahnya sukses. Yang terjadi sebenarnya: mount dilepas dari pohon direktori, tapi proses lama tetap menulis ke filesystem yang sudah "hilang". Datanya tidak muncul di mount point baru dan tidak ada di tempat lama. Jangan pakai -l untuk menutupi proses yang belum selesai.

🔹 Langkah 6: Uji D — memeriksa filesystem dengan benar

Coba dulu saat masih ter-mount, supaya kamu tahu peringatannya: 

e2fsck -n /dev/loop0p1

Lalu lepas mount dan periksa dengan benar: 

umount /mnt/lab
dumpe2fs -h /dev/loop0p1 | egrep 'Filesystem state|Mount count|Maximum mount count|Last checked|Errors behavior'
e2fsck -fn /dev/loop0p1
e2fsck -f -p /dev/loop0p1

-n berarti baca saja dan jawab "tidak" untuk semua pertanyaan. -f memaksa pemeriksaan penuh walau filesystem dianggap bersih. -p memperbaiki otomatis masalah yang aman diperbaiki.

🔥 Kasus nyata: Sebuah kantor distributor menjalankan backup malam ke USB yang di-mount di /mnt/backup. Suatu malam umount gagal karena skrip rsync masih berjalan. Admin memakai umount -l supaya tidak mengganggu jadwal. Rsync terus menulis ke filesystem yang sudah terlepas, sementara folder /mnt/backup kembali kosong — dan rsync berikutnya menulis ke disk sistem. Tiga bulan kemudian, saat restore dibutuhkan, tidak ada satu pun file backup di USB.

📊 Angka penting: Kode keluar e2fsck adalah penjumlahan kondisi: 0 berarti tidak ada error, 1 berarti error diperbaiki, 2 berarti diperbaiki dan sebaiknya reboot, 4 berarti ada error yang belum diperbaiki. Skrip backup yang hanya mengecek "sukses atau gagal" akan salah membaca angka 4.

Sekarang pelajari cara memaksa pemeriksaan saat boot: 

tune2fs -E force_fsck /dev/loop0p1
tune2fs -l /dev/loop0p1 | egrep 'Filesystem state|Errors behavior'
tune2fs -e remount-ro /dev/loop0p1

💡 Tips: tune2fs -E force_fsck menandai superblock seolah ada error, sehingga fsck berjalan pada mount berikutnya. Flag ini dibaca oleh layanan fsck saat boot untuk entri fstab dengan passno 2 — bukan oleh perintah mount biasa. Opsi -e remount-ro membuat filesystem berubah jadi read-only saat menemukan error, jauh lebih baik daripada terus menulis di atas kerusakan.

🔹 Langkah 7: Uji E — menguji fstab tanpa reboot

Siapkan mount point dan ambil UUID asli: 

mkdir -p /mnt/lab
blkid -s UUID -o value /dev/loop0p1

Tambahkan satu baris ke /etc/fstab (ganti bagian UUID dengan hasil di atas): 

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  /mnt/lab  ext4  defaults,nofail  0  2

Sekarang uji tanpa benar-benar melakukan syscall mount: 

findmnt --verify --verbose
mount -a -f -v
systemd-escape -p --suffix=mount /mnt/lab

mount -a -f melakukan semua langkah kecuali syscall sebenarnya. Manual mount(8) menyebutnya "fakes" mounting — persis alat yang kamu butuhkan untuk menguji fstab di server hidup.

Nama unit yang dicetak systemd-escape adalah mnt-lab.mount. Pakai nama itu untuk menguji kegagalan dengan aman: 

systemctl daemon-reload
systemctl start mnt-lab.mount
systemctl status mnt-lab.mount
journalctl -u mnt-lab.mount -n 20 --no-pager

Sekarang rusak satu huruf UUID di /etc/fstab, ulangi daemon-reload dan start. Unit akan failed dengan pesan "can't find UUID=". Di sinilah kamu melihat sendiri kenapa nofail penting: tanpa itu, kegagalan yang sama terjadi saat boot dan sistem berhenti di emergency mode.

🧪 Uji cepat: systemctl list-units --type=mount --all memperlihatkan semua mount unit beserta statusnya. Mount yang hilang dari daftar berarti tidak pernah diminta oleh fstab maupun service lain.

Kembalikan UUID yang benar sebelum lanjut.

🔹 Langkah 8: Uji F — memperluas filesystem

Ingat sisa 300 MiB di image? Sekarang kita pakai. Urutannya wajib: disk, partisi, filesystem. 

umount /mnt/lab
truncate -s +300M /srv/lab-disk/disk-lab.img
losetup -c /dev/loop0
lsblk /dev/loop0

losetup -c menyegarkan ukuran loop device agar mengikuti ukuran file. Tanpa itu, kernel masih mengira disknya 1 GiB. 

parted -s /dev/loop0 resizepart 1 100%
partx -u /dev/loop0
lsblk /dev/loop0

Sekarang partisi sudah memenuhi disk. Perhatikan bahwa filesystem belum ikut membesar — ini titik di mana banyak orang berhenti dan bingung. 

e2fsck -f /dev/loop0p1
resize2fs /dev/loop0p1
mount /dev/loop0p1 /mnt/lab
df -h /mnt/lab

Kalau kamu menjalankan resize2fs sebelum partx -u, hasilnya "Nothing to do!" — bukan karena perintahnya salah, tapi karena partisinya memang belum besar.

🔥 Kasus nyata: Sebuah VM di Proxmox ditambah disknya dari 40 GB ke 80 GB. Admin langsung menjalankan resize2fs /dev/sda1 dan mendapat "Nothing to do!". Karena mengira disknya rusak, dia menyiapkan rencana reinstal server selama satu hari. Setelah dicek, partisi masih 40 GB. Dua perintah — growpart /dev/sda 1 dan resize2fs /dev/sda1 — menyelesaikan semuanya dalam dua menit tanpa downtime.

📊 Angka penting: Pada disk nyata, growpart /dev/sda 1 menolak memperbesar kalau tambahannya kurang dari 10 MiB (nilai --fudge bawaan 20480 sektor). Kalau kamu menambah 5 MB dan tidak terjadi apa-apa, itu penyebabnya.

💡 Tips: ext4 bisa diperbesar saat masih ter-mount (growpart lalu resize2fs), sedangkan XFS memakai xfs_growfs /mountpoint. Memperkecil jauh lebih berisiko dan wajib offline — untuk lab, biasakan unmount dulu supaya urutannya terlihat jelas.

🔹 Langkah 9: Bersihkan dan catat

umount /mnt/lab
losetup -d /dev/loop0
rm -rf /srv/lab-disk

Hapus juga baris uji dari /etc/fstab, lalu jalankan systemctl daemon-reload. Kalau tidak, boot berikutnya akan mengeluh karena mount point-nya kosong.

🏭 Dipakai di dunia kerja

  • Sekolah dan lab CBT: server ujian menyimpan session dan jawaban sementara di disk yang sama dengan sistem. Saat 300 siswa login serentak, jumlah file kecil melonjak dan inode habis lebih dulu daripada ruang.
  • Kantor distributor: backup harian ditulis ke USB yang di-mount manual. Kalau mount gagal dan tidak ada yang sadar, file backup menumpuk di direktori kosong dan disk sistem yang penuh.
  • Hosting dan VPS: satu disk dipakai bersama puluhan situs. Disk penuh berarti semua situs error 500 sekaligus, jadi monitoring harus memantau blok dan inode.
  • Rumah sakit: penyimpanan hasil pencitraan tumbuh cepat dan tidak boleh berhenti. Perluasan volume harus bisa dilakukan tanpa mematikan layanan.
  • ISP dan warnet: log billing serta cache proxy menghasilkan jutaan file kecil per bulan — kasus inode klasik yang tidak terlihat di dashboard kapasitas.
  • Cloud dan container: volume Docker hidup di bawah /var/lib/docker. Image lama yang menumpuk membuat node penuh walau aplikasi tidak menulis data baru.

✅ Verifikasi

Jalankan di akhir praktikum. Kolom terakhir adalah yang paling penting: apa artinya kalau hasilnya berbeda.

Yang diperiksa Perintah Hasil sehat
Perangkat terdeteksi lsblk /dev/loop0 disk dan partisi tampil
Filesystem ada blkid /dev/loop0p1 TYPE="ext4", ada LABEL
Mount menempel findmnt /mnt/lab SOURCE dan TARGET benar
Blok df -h /mnt/lab Use% wajar, bukan 100%
Inode df -i /mnt/lab IUse% wajar, bukan 100%
Status filesystem dumpe2fs -h /dev/loop0p1 state "clean"
fstab bisa dibaca findmnt --verify 0 error
Setelah perluasan df -h /mnt/lab ukuran naik sesuai

🧪 Uji cepat: df -h /mnt/lab; df -i /mnt/lab dalam satu baris adalah pemeriksaan pertama yang harus kamu jalankan setiap kali ada keluhan "disk penuh". Dua angka, dua kemungkinan penyebab.

Kalau findmnt --verify melaporkan error, jangan reboot. Perbaiki dulu, lalu ulangi sampai bersih.

⚠️ Kesalahan umum & troubleshooting

Gejala / pesan Penyebab Tindakan
wrong fs type, bad superblock filesystem belum dibuat atau device salah cek blkid, ulangi mkfs di device yang benar
can't find UUID=... UUID salah ketik atau berubah setelah format ambil ulang dengan blkid -s UUID -o value
special device does not exist kernel belum membaca tabel partisi partx -u atau losetup -c
target is busy ada proses dengan cwd atau file terbuka fuser -vm, tutup prosesnya
Nothing to do! (resize2fs) partisi belum diperbesar growpart atau parted resizepart dulu
No space left, df -h lega inode habis df -i, hapus file kecil, atur rotasi log
Structure needs cleaning ext4 menemukan kerusakan metadata unmount, lalu e2fsck -f
Cannot continue, aborting e2fsck dijalankan pada filesystem ter-mount unmount dulu, atau pakai -n
mount unit failed UUID salah, atau mount point hilang journalctl -u mnt-lab.mount
boot berhenti di emergency mode entri fstab gagal tanpa nofail login sebagai root, perbaiki fstab, systemctl daemon-reload

💡 Tips: Saat boot gagal karena fstab, tambahkan nofail pada data yang tidak kritis, dan x-systemd.device-timeout=10s untuk disk eksternal. Sistem jadi tetap bisa masuk, dan kamu bisa memperbaiki dari dalam.

🔐 Catatan keamanan & etika

  • Perintah disk tidak punya tombol undo. mkfs, parted, dan resize2fs langsung mengubah struktur. Selalu cek nama device dengan lsblk -o NAME,SIZE,MODEL,SERIAL sebelum menekan Enter.
  • fstab setara akses root saat boot. File ini dibaca sebelum banyak layanan berjalan. Jaga kepemilikan root:root dan mode 0644. Siapa pun yang bisa menulis ke sini bisa mengubah apa yang dijalankan sistem.
  • Media lepas jangan dipercaya. Untuk flashdisk atau disk eksternal, pakai opsi nosuid,nodev,noexec agar isinya tidak bisa dipakai menjalankan program atau menaikkan hak.
  • lost+found bisa berisi data yang seharusnya hilang. Setelah fsck, folder ini kadang menyimpan potongan file lama. Jangan dibagikan sembarangan; bisa memuat data pribadi pengguna lain.
  • Hapus image lab dengan sadar. File image menyimpan isi filesystem apa adanya. Kalau kamu pernah menyalin data nyata ke dalamnya, hapus dengan aman, bukan sekadar memindahkan filenya.
  • Etika di server bersama. Jangan menguji umount, resize2fs, atau e2fsck -y di server yang dipakai orang lain. Siapkan snapshot VM atau pakai loop device seperti praktik ini.

⚠️ Hati-hati: Hindari e2fsck -y pada data penting saat pertama kali memeriksa. Jawaban "ya" untuk semua pertanyaan bisa memindahkan banyak file ke lost+found. Mulai dengan -n untuk melihat, baca laporannya, baru tentukan langkah.

📌 Kesimpulan

  • Diagnosa disk berjalan berlapis: perangkat, partisi, filesystem, mount. Berhenti di lapis pertama yang gagal.
  • "No space left on device" bisa berarti blok habis atau inode habis. Selalu periksa df -h dan df -i.
  • umount yang gagal adalah informasi, bukan gangguan. Cari prosesnya dengan fuser -vm, jangan ditutupi dengan -l.
  • e2fsck hanya jujur saat filesystem tidak ter-mount, dan kode keluarnya perlu dibaca sebagai angka, bukan sekadar sukses/gagal.
  • Memperluas filesystem selalu dua langkah: partisi dulu, filesystem kemudian.
  • fstab bisa diuji tanpa reboot lewat findmnt --verify, mount -a -f, dan mount unit systemd.

Langkah berikutnya: ulangi seluruh praktik ini pada VM dengan disk tambahan sungguhan, lalu bandingkan hasil lsblk sebelum dan sesudah perluasan — supaya kamu melihat sendiri tiga ukuran yang berubah satu per satu.

🔗 Materi terkait

📚 Referensi

Retrieved from "https://noctkj.net/index.php?title=Linux_:_Praktikum_Mount,_fsck,_dan_Perluasan_Filesystem&oldid=1701"