Mayoritas benchmark filesystem yang dikutip orang di forum dan deck presentasi mengukur hal yang sama: tulis sekuensial besar, baca acak dengan cache panas, lalu ambil satu angka throughput. Polanya lahir dari era ketika beda antar filesystem masih kelihatan di angka itu. Sebuah proyek benchmark modern yang menguji btrfs, ZFS, bcachefs, XFS, ext4, dan LVM justru berangkat dari keberatan sebaliknya: ada kelas perilaku penting yang lolos total dari pola uji klasik, padahal di situlah pilihan filesystem terasa setiap hari oleh sysadmin.
Halaman "modern-fs-benchmark" milik Bartosz Fenski menampilkan dataset hidup berupa kartu-kartu metrik hasil ratusan run di CI, lengkap dengan penjelasannya. Artikel ini membedah sisi metodologinya, karena justru bagian itu yang bisa dicuri untuk dipakai di lab sendiri, terlepas dari filesystem mana yang menang di dataset sang penulis.
Fondasi Uji: Loop Device, 4 vCPU, dan Ratusan Run
Setup dasarnya bukan SSD nvme colok langsung, melainkan filesystem di atas loop device yang dijalankan di runner CI dengan 4 vCPU. Pilihan ini terdengar aneh sampai dibaca tujuan pembatasannya: konfigurasinya harus bisa diulang persis di setiap run tanpa hardware khusus. Untuk topologi redundansi, penulisnya membuat variasi yang merepresentasikan susunan dunia nyata, seperti md/LVM RAID10, dua pasang mirror ZFS striped, Btrfs RAID1, sampai bcachefs dengan replicas=2 di atas empat loop device; level RAID6 diwakili md RAID6, RAIDZ1/RAIDZ2, dan bcachefs erasure coding.
Hasilnya disimpan sebagai data mentah per run, bukan tabel angka di artikel. Satu kartu per metrik, seratus run terbaru ditampilkan individual, dan run yang lebih tua diringkas jadi median harian. Konsekuensinya penting untuk pembaca: angka yang muncul di halaman itu punya interval, ada variasinya, dan tren antar konfigurasi bisa dibaca dari sebarannya, bukan cuma rata-ratanya.
Kenapa tulis Satu Thread Tidak Mengungkap Apa-apa
Fase dasar tetap ada: tulis sekuensial file baru dengan bs=1M, ukuran 2G, satu job, satu fsync di akhir; lalu padanannya untuk read penuh satu pass tanpa looping, setelah cache didinginkan. Fase-fase ini penting sebagai baseline. Tapi poin artikel ini mulai di fase random write: fio dijalankan dengan numjobs=4, satu file per thread, dengan fdatasync setiap 16 IO.
Alasannya dikutip langsung dari penjelasan di halaman itu: arsitektur locking filesystem baru kelihatan di bawah konkurensi. Bahkan penulisnya mengutip pernyataan pembuat bcachefs bahwa di sanalah variasi antar filesystem paling besar. Cara bacanya sederhana: bandingkan skor 4 thread dengan skor 1 thread. Scaling di atas satu kali berarti paralelisme bekerja; di bawah satu kali berarti kontensi lock yang berbicara. Benchmark satu thread tidak akan pernah menangkap perbedaan itu, padahal server produksi yang sesungguhnya jarang menulis sendirian, selalu ada proses lain yang ikut antre di blok yang sama.
Ekor Latensi: Saat Rata-rata IOPS Berbohong
Metrik favorit dunia hosting adalah IOPS, dan halaman ini justru menempatkan dua kartu persentil di sebelahnya: p99 dan p99.9 dari latensi fdatasync hasil fase random write. Masalah yang mau ditangkap: commit transaksi pada filesystem copy-on-write terjadi berkala, sekitar tiap 5 detik pada ZFS lewat txg, dan pada interval commit btrfs. Peristiwa itu muncul sebagai lonjakan berkala yang tidak kelihatan di rata-rata IOPS.
Contoh paling tajam yang disebut penjelasannya: konfigurasi mirror dengan blok 8k terkenal mencetak IOPS dan p99 yang bagus, sementara p99.9-nya meledak sampai sekitar 180 milidetik. Aplikasi yang merasakan ekor distribusi itu bukan yang hitungannya banyak dan sabar, tapi yang menunggu satu sinkronisasi dan harus menjawab ke user: jurnal transaksi, database, atau layanan antrian.
Cache Dingin dan Jebakan "Membaca Kecepatan RAM"
Fase pembacaan acak di halaman itu dirancang melawan cache. File 2G dibaca acak per blok 4k, tapi hanya satu pass atas 512M blok berbeda, karena loop berbasis waktu akan mencampur baca dingin dengan cache hit dan melaporkannya sebagai satu angka campuran. Sebelum mulai, page cache dijatuhkan; dan ini detail favorit penulisnya: drop_caches tidak menyentuh ARC milik ZFS, sehingga pool ZFS harus di-export lalu di-import ulang supaya dinginnya setara. Untuk pembacaan sekuensial pun berlaku aturan sama, satu pass penuh tanpa mengulang, karena blok yang terbaca ulang berarti laporan kecepatan RAM, bukan kecepatan filesystem.
Ada juga catatan jujur soal batasannya sendiri: uji baca paralel pada mirror dimaksudkan menunjukkan kemampuan replica melayani baca bersamaan, tapi di CI semua replica berada di atas satu disk fisik yang sama, sehingga keuntungan bandwidth-nya hanya akan muncul di hardware nyata. Halaman itu menuliskannya terang-terangan, sesuatu yang jarang ditemui di postingan benchmark yang mengklaim hasil.
Probe Interaktivitas: "Berapa Lama Prompt Kembali"
Fase paling relevan untuk workstation adalah probe durabilitas-latensi yang dirancang penulisnya sebagai kustom, dan dia sendiri menyebutnya "terinspirasi dari tulis-menulis interaktif, bukan model literal setiap shell atau editor". Bentuknya: satu tulis 4k plus fsync tiap 200 milidetik selama 10 detik, kira-kira 50 operasi. Versi keduanya sama, tapi diukur selama 30 detik sambil satu job fio lain membanjiri filesystem dengan streaming write 1M.
Yang diukur di sini adalah efek entanglement commit CoW: fsync kecil ikut menunggu transaksi writer besar. Metrik pelengkapnya namanya langsung menjelaskan niatnya: rasio starvasi, berapa operasi selesai dari sekitar 145 yang diizinkan ritme 200ms; 140-an berarti terminal tetap responsif, satu digit berarti prompt jadi sandera streaming writer. Dan karena satu operasi bisa memakan sekitar 17 detik, penulisnya sadar statistik bisa menipu: histogram latensi fio bertingkat logaritmik sekitar 1,5 persen, sehingga nilai ekstrem terkuantisasi ke bucket yang sama, dan dengan 1 sampai 2 sampel, p99 praktis sama dengan max. Karena itu operasi-selesai jadi angka utama, bukan persentilnya.
Metadata, Snapshot Menua, dan Skenario Ruang Penuh
Sisa fase-fasenya menutup celah yang bahkan lebih jarang diuji. Pohon 20.000 file berukuran 1 sampai 8k di 200 direktori dibuat oleh 4 worker paralel di subset direktori berbeda untuk memancing kontensi lock metadata, dengan perbandingan eksplisit arsitekturnya: tree lock btrfs, paralelisme per-AG XFS, desain b-tree bcachefs; lalu fase terpisah membuat 100.000 file kosong serial dalam satu direktori untuk mengisolasi perilaku indeks satu direktori. Untuk snapshot, ada kurva aging: file 2G ditimpa 64M random write 4k per iterasi dengan snapshot sebelum setiap iterasi, sampai 100 iterasi sejauh teknologinya sanggup, hanya 10 untuk ZFS recordsize default 128K karena setiap snapshot mem-pin hampir seluruh file, dan 8 untuk dm-snapshot LVM. Fase penghancurannya juga dihitung: menghapus seluruh snapshot aging, lalu bulk delete 500 snapshot dengan mekanisme native masing-masing, satu panggilan subvolume delete di btrfs yang kembali dalam milidetik sementara cleaner bekerja belakangan, destroy berjenjang sekali panggil di ZFS, per-snapshot di bcachefs. Ada pula uji kompresi zstd dengan data 75 persen kompresibel yang diukur rasionya lewat alat native (compsize untuk btrfs, compressratio untuk ZFS, delta pemakaian per replika untuk bcachefs) plus catatan bahwa btrfs tidak mengompresi ke extent yang sudah dialokasikan di muka. Terakhir fase pengisian: isi sampai 99 persen versi df, lanjutkan sampai ENOSPC sungguhan, hapus satu file, lalu verifikasi ruang benar-benar kembali dan tulis baru berhasil, pasangan kartu yang menentukan verdict "sistem masih bisa diselamatkan atau tidak".
Tiga fase metadata, snapshot, dan pengisian ruang itu sengaja diletakkan jauh di bawah tabel IOPS karena memang bukan kategori yang bisa diringkas satu angka. Kontensi tree lock hanya muncul kalau ada writer paralel; harga sebuah snapshot baru terasa setelah ratusan snapshot menua; dan perilaku di ambang ENOSPC adalah kelas bug tersendiri yang jarang tertangkap uji happy path. Kombinasi ketiganya membentuk kesan yang lebih jujur soal pemakaian bertahun-tahun di server yang tidak pernah di-reinstall.
Semua fase di halaman aslinya berjalan otomatis di CI dan bisa dipicu ulang, jadi angka yang tampil selalu berasal dari mesin dan kernel yang tercatat, bukan dari screenshot manual yang kebetulan bagus. Transparansi seperti inilah yang membedakan dataset yang bisa diajak berdebat dengan benchmark yang cuma bisa dikutip.Apa yang Bisa Dicuri untuk Lab Sendiri
Tidak perlu punya halaman interaktif seperti aslinya untuk mengambil manfaat metodologinya. Ada lima prinsip yang bisa langsung diterapkan pada benchmark filesystem versi sendiri. Pertama, pisahkan angka concurrency scaling dari angka single thread, lalu interpretasikan rasionya sebagai sinyal lock. Kedua, selalu laporkan persentil ekor untuk operasi yang berujung fsync, karena rata-rata menyembunyikan transaksi CoW berkala. Ketiga, dinginkan cache secara spesifik per filesystem, termasuk detail ARC ZFS yang tidak patuh pada drop_caches. Keempat, ukur interaktivitas sebagai rasio operasi-selesai di bawah banjir write, bukan sebagai persentil mentah yang mudah menipu di sampel kecil. Kelima, masukkan fase pengisian sampai penuh dan fase penghancuran massal snapshot, dua kondisi yang justru sering dialami produksi tapi hampir tidak pernah masuk ke uji pembanding manapun.
Dengan lima prinsip itu, benchmark tidak lagi menjawab pertanyaan "siapa paling cepat" yang jawabannya memang berubah tiap rilis, tapi mulai menjawab pertanyaan yang lebih berguna untuk operasional: siapa yang paling bisa diandalkan menanggung pola tulis campur, beban metadata, dan ruang yang menipis, selama mungkin, tanpa perilaku yang bikin panik jam tiga pagi.
Sebelum Memilih: Konteks yang Sering Terlupa
Satu pengingat sebelum membawa angka mana pun ke produksi. Hasil benchmark loop device di atas filesystem virtual tidak identik dengan NVMe langsung, dan penulis halaman itu sendiri mengingatkan ada metrik yang hanya muncul di hardware nyata. Pilihan filesystem di dunia kerja juga jarang tunggal: kebutuhan pool ZFS dengan recordsize khusus untuk database beda dengan btrfs untuk laptop yang butuh snapshot rollback, dan bcachefs untuk eksperimen baru saja naik ke status stabilnya. Karena itu dataset terbuka seperti modern-fs-benchmark paling berguna sebagai daftar periksa beban uji, bukan sebagai podium. Untuk yang sedang menakar sisi ZFS-nya, artikel fitur baru OpenZFS 2.4 dan kebiasaan keliru soal cache dan storage di aplikasi di Toolkuy bisa jadi pasangan baca yang nyambung sebelum menyusun lab uji sendiri.
💬 Komentar (0)
Belum ada komentar. Jadilah yang pertama! 💬