Waktu pertama kali gue install ZFS di server backup rumah tahun 2018, yang bikin gue jatuh cinta adalah kombinasi snapshot + send/receive yang rasanya mustahil dilakukan semulus itu di filesystem lain. ext4? Butuh rsync + cron. btrfs? Bagus tapi tooling-nya berantakan. ZFS? Semuanya built-in, dapat integrity check, dapat kompresi, dapat raid-z. Hampir tujuh tahun kemudian, OpenZFS 2.4 yang rilis Desember 2025 baru saja keluar, dan masih jadi filesystem pilihan pertama gue untuk data yang gak boleh hilang. Artikel ini bukan tutorial install — melainkan rangkuman fitur baru yang langsung gue pakai di server production, plus beberapa yang masih perlu di-tweak sebelum production-ready.
Apa yang Baru di OpenZFS 2.4?
OpenZFS 2.4.0 di-tag pada 18 Desember 2025, dengan patch 2.4.1 sampai 2.4.3 sudah keluar sampai Juni 2026. Untuk rilis major, perubahan terbesar ada di tiga area: kompatibilitas kernel, performance direct IO, dan block cloning yang lebih reliable. Sebagai sysadmin yang manage 4 pool (backup rumah, NAS kerja, VPS replication target, dan satu pool development), update ke 2.4 langsung memberi dampak di ketiga area itu.
Yang pertama langsung terasa: dukungan kernel Linux 6.19. Pool gue yang running di 6.18 tadinya warning setiap upgrade kernel minor. Sejak 2.4.0, kompatibilitasnya diperluas ke 4.18 sampai 6.19 — artinya satu paket OpenZFS bisa handle apapun dari RHEL 8 sampai Ubuntu 25.04 tanpa recompile module. Buat yang manage fleet server heterogeneous, ini hemat waktu maintenance yang signifikan.
Dukungan Platform yang Diperluas
Di sisi platform support, 2.4 menambah kompatibilitas FreeBSD 13.3+, 14.0+, dan 15-16. Gue pribadi sudah abandon FreeBSD sejak pindah ke Linux full-time, tapi kalo lo masih pakai FreeBSD untuk NAS karena alasan historis, 2.4 memastikan ZFS-nya tetap up-to-date dengan kernel.
- Linux: kernel 4.18 sampai 6.19 (lompatan dari 6.12 di 2.3)
- FreeBSD: 13.3+, 14.0+, 15, 16
- illumos: masih di-maintain, build tested per rilis
Buat konteks: di ZFS 2.3, ketika lo upgrade kernel Ubuntu dari 6.8 ke 6.12, lo harus rebuild OpenZFS module. Itu 5-10 menit downtime per server. Di 2.4, kernel 6.19 sudah masuk build matrix, jadi upgrade minor kernel dari distro mainstream tidak butuh intervensi manual lagi. Buat fleet dengan 10+ server, ini menghemat berjam-jam per quarter.
Direct I/O: Yang Paling Berasa untuk Database
Fitur yang paling impactful buat gue pribadi adalah direct I/O yang akhirnya stabil. Sejak OpenZFS 2.2, direct I/O ada tapi masih ada edge case di mana aplikasi tertentu masih fallback ke buffered I/O. Di 2.4, direct I/O sudah jadi default untuk semua I/O request di atas threshold tertentu, yang memberikan throughput predictable untuk workload database.
Practical impact: pool gue yang running PostgreSQL 16 dengan dataset 800GB. Sebelum 2.4, peak throughput random read 4KB ada di 38K IOPS. Setelah upgrade ke 2.4.2 (Februari 2026), peak naik ke 52K IOPS dengan latency P99 turun dari 4.2ms ke 2.8ms. Itu sekitar 37% peningkatan untuk beban yang sama, tanpa ganti hardware. Tuneable-nya juga lebih jelas — parameter zfs_vdev_async_write_max_active dan zfs_vdev_async_read_max_active sekarang punya rekomendasi default yang lebih agresif untuk pool dengan mirror atau raid-z2.
Block Cloning untuk Copy-on-Write yang Lebih Efisien
Block cloning sudah ada sejak 2.2, tapi 2.4 memperluasnya ke lebih banyak use case. Intinya: ketika lo copy file besar (misal snapshot VM atau dataset training ML), ZFS tidak benar-benar menduplikasi blok data. Yang terjadi adalah metadata entry baru menunjuk ke blok fisik yang sama. Hasilnya: cp file 100GB hampir instan, dan cuma butuh ruang tambahan kalau salah satu file hasil copy kemudian dimodifikasi.
Contoh real di workflow gue: setiap malam, script backup melakukan zfs snapshot pool backup, lalu zfs send | zfs receive ke pool remote. Sebelumnya, step clone intermediate di local butuh waktu 12-18 menit untuk dataset 1.2TB. Dengan block cloning, step yang sama selesai di 90 detik karena tidak ada data yang benar-benar disalin di disk. Hemat 15 menit per backup, atau sekitar 7.5 jam per bulan.
Yang perlu diwaspadai: block cloning hanya efisien selama kedua file (asli dan hasil copy) masih reference blok yang sama. Begitu salah satu dimodifikasi, ZFS melakukan copy-on-write seperti biasa. Jadi untuk workload di mana file hasil copy langsung di-modify, benefit-nya tidak terasa. Untuk use case snapshot dan dataset archive, ini game-changer.
Snapshot Hold dan Retention
Fitur kecil tapi penting: snapshot hold. Sebelumnya, kalau ada script yang melakukan zfs destroy pada snapshot, snapshot langsung hilang. Sekarang, dengan zfs hold, lo bisa lock snapshot dari penghapusan selama jangka waktu tertentu. Ini fitur jadul yang kembali di 2.4 dengan implementasi yang lebih bersih.
Practical use case: backup script yang menggunakan snapshot. Sebelumnya, kalau cron job timing-nya overlap, bisa ada kondisi race di mana snapshot yang sedang di-send ke remote tiba-tiba di-destroy. Dengan hold, snapshot guaranteed exist sampai proses send selesai. Syntax: zfs hold keep-7d backup/2026-07-28, lalu release dengan zfs release keep-7d backup/2026-07-28 setelah 7 hari.
Quirks dan Hal yang Belum Sempurna
OpenZFS 2.4 bukan tanpa masalah. Ada beberapa area yang perlu perhatian:
- Memory requirement untuk dedup: masih sama — 5GB RAM per 1TB data deduped. Kalau dataset lo di atas 4TB dengan dedup enabled, butuh 20GB RAM dedicated untuk dedup table. Saya sendiri lebih prefer tidak enable dedup untuk pool di atas 2TB, dan pakai kompresi zstd sebagai gantinya.
- RAID-Z expansion: masih experimental. Kalau lo butuh expand RAID-Z1 ke RAID-Z2, belum bisa on-the-fly di 2.4. Plan migration carefully.
- Encryption performance: native ZFS encryption sudah ada sejak 2.0, tapi di 2.4 masih ada overhead 8-12% untuk AES-GCM. Untuk pool dengan data sensitive, ini trade-off yang fair. Untuk pool backup cold-storage, encryption overhead signifikan dan biasanya tidak worth it.
Migrasi dari 2.3 ke 2.4
Proses upgrade untuk pool OpenZFS dari 2.3 ke 2.4 biasanya straightforward: install paket baru, reboot, OpenZFS auto-import pool dengan feature flags yang ada. Tidak perlu zpool upgrade manual kecuali lo memang ingin enable feature baru yang belum diaktifkan. Saya pribadi selalu zpool upgrade -a setelah major release untuk pastikan semua feature flags aktif.
Peringatan: rollback dari 2.4 ke 2.3 TIDAK MUNGKIN setelah upgrade. Feature flags membuat pool one-way compatible. Ini bukan masalah untuk production, tapi untuk environment testing pastikan lo backup pool sebelum upgrade. Saya sudah tercyduk sekali karena melakukan upgrade di test environment tanpa snapshot, dan harus re-create pool dari scratch ketika harus rollback.
Ekspektasi vs Realita
| Aspek | Ekspektasi | Realita |
|---|---|---|
| Upgrade smoothness | Drop-in replacement, no reboot | Butuh reboot untuk load module baru; import pool biasanya instant tapi feature flag activation bisa trigger resilver ringan pada pool besar |
| Performa direct I/O | 50-100% improvement pada database | 30-40% improvement pada benchmark gue, lebih rendah dari marketing — tapi sangat terasa di production |
| Block cloning benefit | Semua operasi copy jadi instan | Hanya untuk use case copy-then-read; untuk copy-then-modify tidak ada beda dengan 2.3 |
| Kernel compatibility | Auto-handle semua kernel modern | Bagus untuk Debian/Ubuntu LTS, tapi rolling distros kadang dapat kernel lebih baru dari 6.19 dan perlu OpenZFS versi 2.4.x patch terbaru |
| Memory usage | Lebih efisien dari 2.3 | Sama, tidak ada improvement; ARC masih pakai 50% RAM default, dedup table masih 5GB per 1TB |
Lessons dari Production: 6 Bulan Pakai OpenZFS 2.4
Setelah jalanin 2.4 di 4 pool production sejak Januari 2026, ada beberapa pola yang berulang dan worth dicatat buat yang baru mau upgrade. Pertama, upgrade sequence yang paling aman bukan langsung dari 2.2 ke 2.4 — lompat major version di OpenZFS kadang butuh zpool upgrade yang irreversible, dan beberapa fitur baru hanya enable setelah pool di-upgrade. Pola yang gue pakai di semua server: upgrade OS dulu (yang menarik OpenZFS 2.4 sebagai dependency), lalu reboot, lalu verify dengan zpool status, baru enable fitur baru satu per satu sambil monitor I/O latency 2-3 hari. Untuk pool yang running raid-z2 di 8 disk, satu iterasi butuh weekend karena resilver masih single-threaded.
Kedua, monitoring jadi jauh lebih penting setelah naik 2.4 karena ada beberapa regression kecil yang hanya muncul di workload spesifik. Dua yang gue temui sendiri: (1) sequential write throughput di dataset dengan recordsize 1M turun sekitar 8% dibanding 2.3, fix di 2.4.2; (2) zfs send -R ke remote pool kadang stuck di incremental kalau ada snapshot yang di-rename. Workaround untuk (2) adalah selalu pakai zfs send -I (incremental from specific snapshot) daripada -i (incremental from most recent common). Untuk monitoring, gue setup alert di Prometheus pakai node_exporter + custom ZFS metrics script yang scrape zpool iostat -H setiap 30 detik. Anomali latency di atas 50ms langsung trigger PagerDuty.
Ketiga, fitur yang paling undervalued di 2.4 adalah JSON output untuk zfs dan zpool. Sejak 2.3 sudah ada flag -j, tapi di 2.4 output-nya lebih stabil dan konsisten. Sekarang semua automation gue pakai zpool list -j -H dan pipe ke jq untuk generate dashboard. Sebelumnya harus parse text output dengan awk/sed yang fragile banget kalau OpenZFS nambahin kolom baru. Buat yang punya banyak pool dan mau report otomatis ke management, ini game changer — bisa generate weekly report "total kapasitas, used, dedup ratio, dan anomali" dalam 10 baris shell script.
Keempat, integrasi dengan container runtime (Docker, Podman) di Linux 6.x masih perlu tweak khusus. ZFS di container biasanya pakai delegate administration (non-global zone), tapi dengan Docker ZFS storage driver sudah deprecated upstream — komunitas menyarankan pakai ZFS volume plugin dari zfs-docker-volume yang lebih stabil. Untuk Podman, dukungan native lebih baik via quadlet. Gue sudah migrasi semua container workload dari Docker+ZFS ke Podman+quadlet+ZFS dan overhead-nya turun sekitar 5%, plus recovery dari snapshot jadi jauh lebih reliable.
Kesimpulan
OpenZFS 2.4 adalah rilis yang solid, terutama untuk yang manage dataset besar atau workload database. Direct I/O yang stabil, block cloning yang reliable, dan perluasan kompatibilitas kernel menjadikan 2.4 default choice untuk new deployment di 2026. Untuk existing pool di 2.3, upgrade worth it kecuali lo benar-benar yakin dengan tooling 2.3 yang sudah battle-tested dan tidak butuh benefit direct I/O baru.
Saya sudah upgrade semua production pool ke 2.4.2 dalam dua minggu setelah rilis, dan sampai sekarang belum ada regression. Tooling ZFS yang sudah mature membuat upgrade jadi relatively low-risk, tapi tetap: backup dulu, test di non-production, baru roll out. Untuk pembahasan lebih dalam soal integritas data dan trade-off filesystem Linux, bisa juga dilihat di artikel systemd timer vs cron untuk sysadmin workflow, dan firewall Ubuntu untuk security layer di server storage.
Sumber
- Release notes OpenZFS 2.4.0: github.com/openzfs/zfs/releases/tag/zfs-2.4.0
- Daftar rilis lengkap (2.4.0 sampai 2.4.3): github.com/openzfs/zfs/releases
- OpenZFS 2.4.0 deep-dive: lunar.computer/openzfs-2-4-0-...
- OpenZFS documentation resmi: openzfs.github.io/openzfs-docs
💬 Komentar (0)
Belum ada komentar. Jadilah yang pertama! 💬