Belajar Linux Filesystem - Filesystem Selection Guide

#Pendahuluan

Setelah 17 episode mempelajari setiap filesystem secara mendalam, episode 18 menjawab pertanyaan paling praktis: mana yang harus saya pilih? Tidak ada jawaban universal — yang ada adalah kerangka keputusan yang mempertimbangkan workload, tim, dan realitas dukungan.

Episode ini menyusun panduan pemilihan untuk ext4, XFS, btrfs, ZFS, dan tmpfs. Lalu kita membahas tradeoff yang sering diabaikan: biaya fitur, overhead RAM ZFS, dan politik dukungan vendor. Pada akhirnya kalian akan mendapat checklist yang bisa dijalankan di proyek nyata.

Ingat prinsip dari episode 10: cocokkan filesystem dengan workload, bukan sebaliknya.

#Profil Tiap Filesystem

#ext4: Pilihan Serbaguna

ext4 adalah default Ubuntu dan Debian — filesystem paling teruji dan paling sederhana.

Cocok untuk:

• Root filesystem dan server serbaguna.
• Beban database menengah dengan tuning minimal.
• Tim yang ingin storage tanpa kejutan.

Tidak ideal untuk:

• Kebutuhan snapshot native dan kompresi.
• Filesystem multi-petabyte.

Keunggulan terbesarnya adalah kesederhanaan: dokumentasi lengkap, recovery yang sudah sangat dipahami, dan overhead CPU/RAM yang hampir nol.

#XFS: Throughput Tinggi

XFS adalah default RHEL, Rocky, dan AlmaLinux — dirancang untuk file besar dan beban paralel.

Cocok untuk:

• Server media, backup, dan arsip.
• Beban dengan banyak file besar.
• Lingkungan yang sudah berbasis Red Hat.

Tidak ideal untuk:

• Kebutuhan snapshot native (tidak punya).
• Penyusutan online (tidak bisa menyusut).

#btrfs: Snapshot dan COW Bawaan Kernel

btrfs adalah default openSUSE — membawa snapshot, kompresi, dan checksum ke dalam kernel.

Cocok untuk:

• Sistem yang sering di-update (snapshot rollback).
• Container storage dengan COW.
• Kompresi transparan zstd.

Tidak ideal untuk:

• RAID5/RAID6 yang masih eksperimental.
• Lingkungan yang membutuhkan dukungan vendor Red Hat (deprecate sejak 2024).

#ZFS: Integritas dan Pool

ZFS adalah pilihan TrueNAS dan storage enterprise — integritas, pool, dan RAIDZ dalam satu paket.

Cocok untuk:

• Storage kritis dengan checksum dan self-healing.
• Pool multi-disk dengan RAIDZ atau mirror.
• Deduplication dan kompresi yang kuat.

Tidak ideal untuk:

• Lingkungan dengan RAM terbatas (ARC bisa menelan banyak memori).
• Sistem dengan kebijakan lisensi ketat (GPL/CDDL).

#tmpfs: RAM Cepat

tmpfs menyimpan semuanya di RAM dan swap:

Cocok untuk:

• File sementara, cache, dan socket.
• /dev/shm dan container ephemeral.

Tidak ideal untuk:

• Data yang harus bertahan reboot.

#Tradeoff yang Sering Diabaikan

#Fitur vs Kesederhanaan

Setiap fitur adalah biaya operasional. ZFS dengan snapshot, dedup, dan ARC adalah filesystem terkuat — tapi juga paling kompleks untuk dioperasikan dan di-debug. ext4 yang "membosankan" justru menjadi nilai karena siapa pun bisa mengelolanya.

Pertanyaan jujur untuk ditanyakan: siapa yang akan mengoperasikan storage ini selama tiga tahun ke depan? Jika jawabannya bukan ahli ZFS, pertimbangkan kesederhanaan.

#Overhead RAM ZFS

ARC (Adaptive Replacement Cache) ZFS memakai RAM sistem secara dinamis, sering mencapai setengah memori total pada server besar:

arcstat

Nilai size menampilkan RAM yang dipakai ARC. Atur batasnya:

echo 8589934592 | sudo tee /sys/module/zfs/parameters/zfs_arc_max

Ingat: RAM yang dipakai ARC bukan buangan — itu cache yang mempercepat baca. Tapi server dengan workload lain yang juga butuh memori harus menetapkan batas.

#Dukungan Vendor dan Lisensi

Dua realitas politik yang mempengaruhi pilihan:

• btrfs di Red Hat: di-deprecate sejak RHEL 9.4 — Red Hat tidak lagi merekomendasikannya dan dokumentasinya dihapus. Enterprise yang berbasis RHEL sebaiknya menghindarinya.
• ZFS dan lisensi: modul kernel ZFS berlisensi CDDL, tidak kompatibel dengan GPL. Distribusi seperti Debian mengakomodasi via DKMS, tapi Red Hat tidak mendistribusikannya secara resmi. Ini alasan ZFS tidak pernah menjadi default di distro mainstream.

Konsekuensi praktis: pilihan filesystem kadang ditentukan oleh ekosistem, bukan murni teknologi.

#Kerangka Keputusan

#Alur Memilih

Gunakan alur bertingkat ini:

butuh snapshot native? → ya: btrfs / ZFS
   → butuh pool & RAIDZ? → ya: ZFS
   → bukan: btrfs
butuh throughput besar? → ya: XFS
kebutuhan umum / root / sederhana → ext4
data sementara di RAM → tmpfs

Tiga pertanyaan utama:

1. Apakah butuh snapshot, checksum, atau kompresi? (mengarah ke btrfs/ZFS)
2. Apakah butuh pool multi-disk dan RAIDZ? (mengarah ke ZFS)
3. Apakah workload menuntut throughput besar? (mengarah ke XFS)

#Memvalidasi dengan Benchmark

Jangan pilih berdasarkan opini — ukur di workload nyata. Replay jejak tulis aplikasi kalian dengan fio:

fio --name=uji --rw=randwrite --bs=8k --iodepth=16 --size=2G --direct=1 --runtime=60 --time_based

Jalankan benchmark yang sama di ext4, XFS, btrfs, dan ZFS (dengan recordsize sesuai workload), lalu bandingkan. Data lebih meyakinkan daripada brosur. Gunakan fio --name=uji --rw=randwrite --bs=8k sebagai baseline yang sama untuk semua filesystem agar perbandingannya adil.

#Penutup

Memilih filesystem adalah keputusan yang mempertimbangkan teknologi dan manusia: workload menentukan kebutuhan, tim menentukan kompleksitas yang bisa dikelola, dan ekosistem menentukan dukungan yang tersedia. Tidak ada pilihan sempurna — hanya pilihan yang paling sesuai.

Inti yang harus dibawa pulang:

• ext4 untuk kesederhanaan dan stabilitas; XFS untuk throughput besar.
• btrfs untuk snapshot + COW + kompresi bawaan kernel.
• ZFS untuk integritas, pool, dan RAIDZ; tmpfs untuk data sementara di RAM.
• ARC ZFS memakai RAM besar — atur zfs_arc_max sesuai kebutuhan.
• btrfs di-deprecate Red Hat; ZFS berlisensi CDDL via DKMS.
• Validasi pilihan dengan benchmark di workload nyata, bukan opini.

Di episode 19 selanjutnya kita membahas cloud dan managed storage — perbedaan instance store dan EBS/gp3, filesystem untuk cloud images, object storage S3-compatible, serta EFS, Azure Files, dan GCP Filestore. Kalian akan belajar kapan storage lokal dan kapan layanan terkelola.