Belajar Linux Filesystem - Filesystem untuk Workload Khusus

#Pendahuluan

Sejauh ini kita mempelajari filesystem secara terpisah. Episode 10 mengubah sudut pandang: kalian mulai dari workload, lalu memilih filesystem yang paling cocok. Database punya pola I/O yang berbeda dari file server media; container punya kebutuhan yang berbeda dari root filesystem.

Pilihan yang salah tidak selalu terlihat sebagai error — sering kali berupa performa yang mengecewakan, operasi yang rumit, atau data yang sulit dilindungi. Dengan memahami karakteristik tiap workload, kalian bisa membuat keputusan yang berdasarkan data, bukan kebiasaan.

Episode ini membahas empat kategori: database, container dan VM image, file server media, dan root filesystem. Untuk setiap kategori kita bahas rekomendasi utama dan tradeoff-nya.

#Database: Latency dan Konsistensi

#Karakteristik Beban Database

Database transaksional (PostgreSQL, MySQL) punya pola khas: banyak operasi kecil, fsync yang sering, dan ukuran file yang tetap sepanjang umur. Yang dibutuhkan adalah latency rendah dan konsistensi crash yang bisa diprediksi, bukan throughput besar.

#Pilihan untuk Database

Dua pendekatan utama:

• ext4 atau XFS dengan noatime: prediktif, terbukti, dan tidak ada kejutan dari mekanisme COW.
• ZFS dengan recordsize yang disesuaikan dan ZIL (ZFS Intent Log) di perangkat cepat.

Contoh tuning ZFS untuk database:

sudo zfs create -o recordsize=8k -o atime=off -o primarycache=all labpool/pgdata

recordsize=8k menyamakan unit alokasi dengan ukuran blok PostgreSQL. Untuk workload tulis sync, pertimbangkan sync=always hanya jika dibutuhkan keamanan absolut — dengan konsekuensi performa.

Untuk ext4, pastikan mode data=ordered (default) dan pertimbangkan commit yang lebih kecil agar fsync lebih responsif:

sudo mount -o noatime,data=ordered /dev/loop0 /mnt/db

Aturan sederhana: kalau kalian belum menguasai tuning ZFS, database di ext4/XFS yang bersih hampir selalu menang secara total cost of ownership.

#Container dan VM Images

#Karakteristik Container Images

Image container dan VM dibangun berlapis — setiap layer adalah delta dari layer sebelumnya. Filesystem yang Copy-on-Write paling cocok karena layer bisa berbagi blok tanpa duplikasi. Di sinilah btrfs dan ZFS unggul:

• btrfs: driver storage bawaan Docker (btrfs) memakai subvolume dan snapshot sebagai layer image.
• ZFS: driver zfs memakai dataset dan clone untuk efek yang sama dengan checksum.

#Snapshot untuk Image

Pola yang dipakai adalah snapshot sebagai image template dan clone sebagai instance:

sudo zfs create -V 20G labpool/vm-base
sudo zfs snapshot labpool/vm-base@clean
sudo zfs clone labpool/vm-base@clean labpool/vm-instansi-1

Clone tidak menyalin data sampai diubah — sepuluh VM dari satu template hanya memakai ruang sedikit di atas baseline. Ini alasan utama ZFS dan btrfs mendominasi storage container dan hypervisor modern.

#File Server dan Media

#Karakteristik File Server

File server media (video, foto, backup arsip) didominasi file besar yang ditulis sekali dan dibaca berkali-kali. Kompresi transparan sangat menguntungkan — media teks dan data terkompresi dengan baik, dan rasio penyimpanan naik drastis.

#Pilihan: ZFS atau btrfs dengan Kompresi

ZFS dengan lz4 atau zstd adalah pilihan utama untuk media storage:

sudo zfs create -o compression=zstd -o recordsize=1M labpool/media

recordsize=1M optimal untuk file besar berurutan. Alternatif btrfs:

sudo mount -o compress=zstd,noatime /dev/loop0 /mnt/media

Kedua filesystem ini memberi checksum di atas kompresi — kualitas penting untuk arsip jangka panjang. Untuk sekadar NAS sederhana tanpa integritas, ext4 dengan mount noatime juga cukup.

#Root Filesystem dan Swap

#Root Filesystem: Stabilitas di Atas Segalanya

Root filesystem harus boot dengan andal, mudah diperbaiki, dan tidak bergantung pada mekanisme kompleks. Pilihan umum:

• ext4: pilihan default yang paling aman — bootloader, recovery, dan dokumentasinya paling matang.
• XFS: pilihan default RHEL; stabil untuk root selama partisi dibuat benar.
• btrfs: dipakai openSUSE karena snapshot system update; keunggulannya rollback cepat.

Perhatikan tradeoff btrfs di root: snapshot system update sangat berguna, tapi kalian harus disiplin mengelola subvolume agar tidak penuh. Untuk server tanpa fitur snapshot, ext4 tetap juara kesederhanaan.

#Swap dan tmpfs

Swap tidak membutuhkan filesystem khusus — partisi swap adalah area mentah yang ditandai TYPE=swap. Untuk temp data, tmpfs menyimpan semuanya di RAM:

sudo mount -t tmpfs -o size=1g tmpfs /mnt/ram

tmpfs menghilang saat reboot — cocok untuk cache dan file sementara, dan ideal untuk workload yang sangat cepat membaca-menulis namun tidak butuh persistensi.

#Penutup

Memilih filesystem berarti mencocokkan karakteristik workload dengan kekuatan filesystem. Database butuh latency rendah dan prediktabilitas; container butuh COW untuk layer image; media butuh kompresi dan checksum; root butuh stabilitas di atas segalanya.

Inti yang harus dibawa pulang:

• Database: ext4/XFS noatime atau ZFS dengan recordsize=8k.
• Container dan VM: btrfs atau ZFS karena COW membuat layer dan clone efisien.
• File server media: ZFS zstd atau btrfs compress=zstd.
• Root filesystem: ext4 untuk kesederhanaan, XFS untuk RHEL, btrfs jika butuh snapshot.
• tmpfs menyimpan data di RAM dan cocok untuk file sementara.
• Tidak ada filesystem universal — kecocokan dengan workload adalah segalanya.

Di episode 11 selanjutnya kita membahas repair dan recovery — dari e2fsck, xfs_repair, btrfs check --repair, hingga zpool scrub dan zpool import, plus dasar data recovery dengan ddrescue untuk disk yang mulai rusak. Kalian akan belajar apa yang dilakukan saat yang terburuk benar-benar terjadi.