ZFS 2.3 dirilis, menyertakan fitur ekspansi RAIDZ

 (github.com/openzfs)
1 poin oleh GN⁺ 2025-01-15 | 1 komentar | Bagikan ke WhatsApp
  • OpenZFS 2.3.0 menghadirkan RAIDZ Expansion sebagai fitur utama, yang memungkinkan penambahan perangkat baru ke pool RAIDZ yang sudah ada untuk menambah kapasitas tanpa downtime
  • Fast Dedup secara signifikan meningkatkan performa fitur deduplikasi yang sudah ada, dan juga disertai peningkatan performa di seluruh codebase
  • Direct IO memungkinkan bypass ARC saat baca/tulis, ditujukan untuk lingkungan seperti perangkat NVMe di mana caching dapat menurunkan efisiensi
  • Ditambahkan output JSON opsional untuk perintah yang sering digunakan, dukungan nama file/direktori hingga 1023 karakter, serta perbaikan bug penting yang menangani masalah pada versi sebelumnya
  • Cakupan dukungan meliputi kernel Linux 4.18~6.12 dan FreeBSD 13.3, 14.0~14.2, dan 134 orang berpartisipasi dalam siklus rilis ini

Apa yang berubah di OpenZFS 2.3.0

  • OpenZFS 2.3.0 diperbarui dengan fokus pada ekspansi penyimpanan, performa deduplikasi, jalur I/O, format output perintah, dan dukungan panjang nama file
  • Tag rilisnya adalah zfs-2.3.0, dan mencakup perubahan sejak OpenZFS 2.2.0

Ekspansi penyimpanan dan peningkatan performa

  • RAIDZ Expansion memungkinkan penambahan perangkat baru ke pool RAIDZ yang sudah ada sehingga kapasitas penyimpanan dapat ditingkatkan tanpa downtime
  • Fast Dedup adalah peningkatan performa besar untuk fitur deduplikasi yang sudah ada di OpenZFS
  • Direct IO memungkinkan bypass ARC saat baca/tulis
    • Ditujukan untuk meningkatkan performa dalam situasi seperti perangkat NVMe, ketika caching dapat menghambat efisiensi
  • Berbagai peningkatan performa juga disertakan di seluruh codebase

Output perintah dan panjang nama

  • JSON menambahkan output JSON opsional ke perintah yang paling sering digunakan
  • Long names mendukung nama file dan direktori hingga 1023 karakter

Stabilitas, platform, kontribusi

  • Termasuk perbaikan bug penting yang menangani masalah yang dilaporkan pada versi sebelumnya
  • Platform yang didukung:
    • kernel Linux 4.18~6.12
    • FreeBSD 13.3, 14.0~14.2
  • 134 kontributor berpartisipasi dalam siklus rilis ini

Dokumentasi dan changelog

Perubahan opsi modul

  • Seluruh opsi dan cakupan pengendaliannya dirangkum dalam dokumen module parameters
  • Opsi modul baru mencakup item terkait ekspansi RAIDZ, log deduplikasi, Direct IO, allocator, scrub, dan resilver
    • Contoh: raidz_expand_max_copy_bytes, raidz_expand_max_reflow_bytes, zfs_dio_enabled, zfs_dedup_log_mem_max, zfs_scrub_after_expand
  • Opsi modul yang dihapus:
    • zfetch_array_rd_sz
  • Opsi modul yang diubah:
    • zfs_arc_shrinker_limit
    • zfs_bclone_enabled
    • zfs_vdev_disk_classic
    • zio_taskq_write

Bacaan terkait

1 komentar

 
GN⁺ 2025-01-15
Opini Hacker News

  • Ekspansi ZFS RAIDZ yang sudah dipersiapkan selama bertahun-tahun akhirnya masuk
    Fitur utamanya adalah ekspansi RAIDZ, yang memungkinkan penambahan perangkat ke pool RAIDZ yang sudah ada untuk menambah kapasitas tanpa downtime; deduplikasi cepat yang meningkatkan kinerja deduplikasi OpenZFS secara signifikan; I/O langsung yang meningkatkan kinerja di lingkungan tempat cache bisa tidak efisien, seperti NVMe, dengan melewati ARC; keluaran JSON opsional untuk perintah yang sering digunakan; serta dukungan nama file dan direktori hingga 1023 karakter

    • Lebih tepatnya, ini berarti bisa menambahkan perangkat baru, yaitu disk, ke RAIDZ vdev yang sudah ada
    • Jika menjalankan Proxmox di atas ZFS dan NVMe, saya penasaran apakah sebaiknya mengaktifkan I/O langsung saat 2.3 sudah didistribusikan
      Saya ingin tahu fitur ini cocok untuk penggunaan seperti apa
    • Empat fitur pertama benar-benar tampak sebagai perubahan besar
    • Meski begitu, tampaknya penghapusan vdev masih belum bisa dilakukan
    • Saya penasaran seberapa baik fitur ini telah diuji bersama enkripsi
      Saya juga mempertanyakan apakah tim ZFS benar-benar memperlakukan enkripsi sebagai prioritas kelas satu
      ZFS di Linux memang banyak mewarisi reputasi ZFS di Solaris, tetapi orang yang menggunakannya di lingkungan produksi perlu melihat issue tracker cukup teliti untuk memahami realitasnya

  • Sulit dipahami bahwa Windows, platform PC yang sejauh ini terbesar berdasarkan jumlah pengguna, masih belum memiliki jawaban untuk ZFS
    Microsoft pernah punya WinFS lalu ReFS, tetapi keduanya tersisih; pengembangan memang berlanjut dan sebagian kadang masuk ke Win11, tetapi rilis resminya tidak terlihat
    Beberapa individu mencoba pekerjaan besar untuk membuat lapisan kompatibilitas ZFS, tetapi masih jauh dari matang atau layak dipakai sungguhan
    Saya tidak mengerti bagaimana Windows masih menggunakan file system berusia 32 tahun

    • Sejujurnya, situasi Linux juga tidak jauh lebih baik
      ZFS memiliki masalah lisensi dengan Linux sehingga integrasi penuh terhalang, dan Btrfs sudah 15 tahun dikembangkan tetapi masih belum menyamai ZFS dalam fitur dan stabilitas
      Sebagian besar distribusi Linux masih memakai ext4 yang berusia 19 tahun sebagai default, dan ext4 sebenarnya lebih mirip ekstensi di atas ext2 yang usianya sama dengan NTFS
      Kalau adil, jarang ada komponen sistem operasi sepenting file system, dan banyak orang enggan menyentuh file system yang belum terbukti lebih dari 10 tahun di lingkungan produksi
    • Alasannya sederhana. Sebagian besar beban yang seharusnya dipikul file system diambil alih oleh perangkat keras storage enterprise tempat file system itu berada
      Fitur yang dibutuhkan seperti snapshot, deduplikasi tingkat blok, teknologi object storage, RAID/resiliensi, dan pengubahan ukuran ditangani oleh perangkat storage
      Storage appliance modern hampir seperti ilmu hitam, sehingga NTFS tidak benar-benar membutuhkan lebih banyak fitur
      Cukup akses secara transparan melalui NAS/SAN, atau simpan volume NTFS di atas disk box yang mumpuni
      Di ranah kelas atas dunia Linux ada Lustre dan GPFS, sementara ZFS umumnya cocok untuk penggunaan yang membutuhkan resiliensi meski kinerja bukan fokus utama
    • Di kernel Linux mainline pun tidak ada jawaban yang setara dengan ZFS
      Menurut saya karena ini sulit dan berisiko tinggi, sementara imbalannya umumnya hanya berupa penghormatan teknis
    • Sebagai pengguna akhir yang memakai Windows dan Linux tetapi tidak memakai ZFS, saya penasaran apa yang saya lewatkan
    • OpenZFS untuk Windows sudah mencapai status release candidate (rc11), dan masih ada beberapa bug di sekitar pemasangan volume
      Tidak parah, tetapi untuk saat ini sebaiknya hindari enkripsi, dan laju pengembangannya cepat sampai-sampai release candidate baru keluar setiap beberapa minggu untuk memperbaiki masalah yang tersisa
      Dengan menggabungkannya dengan Storage Spaces untuk melakukan pooling disk dengan jenis atau ukuran berbeda, lalu mendefinisikan lokasi, redundansi, dan tiering per Space, Windows kini menjadi platform storage canggih
      Jika memakai Windows Server, misalnya 2022/2025 Essentials yang murah, di LAN dan di atas virtual hard disk .vhdx Anda juga bisa memakai SMB Direct/RDMA dengan kinerja hingga 10Gbyte/s, sehingga menjadi alternatif yang lebih cepat dan tanpa konfigurasi dibanding iSCSI
      Karena itu, saya mem-porting napp-it cs, GUI web ZFS, dari Solaris ke Windows agar bisa mengelola Storage Spaces dan ZFS, serta server OpenZFS jarak jauh seperti Proxmox, dan gratis untuk penggunaan nonkomersial

  • Saya suka bahwa fitur ekspansinya dibuat cukup konservatif
    Ekspansi tidak hanya sepenuhnya transparan dan bisa dilanjutkan kembali, tetapi juga mempertahankan redundansi sepanjang proses
    Namun ada satu catatan kecil yang perlu diketahui orang
    Setelah ekspansi selesai pun, blok lama tetap mempertahankan rasio data terhadap parity yang lama. Misalnya RAIDZ2 5-wide tetap tersebar di kumpulan disk yang lebih besar dengan kondisi 3 data berbanding 2 parity
    Blok baru ditulis dengan rasio data terhadap parity yang baru. Misalnya jika RAIDZ2 5-wide diperluas sekali menjadi 6-wide, rasionya menjadi 4 data berbanding 2 parity

    • Saya tidak yakin itu benar-benar sebuah catatan. Artinya hanya data lama bisa tetap berada dalam penempatan yang tidak optimal
      Meski begitu, manfaat RAIDZ N tetap sama, sehingga pool tetap berjalan bahkan jika hingga N disk gagal total
    • Catatan itu adalah perilaku yang cukup bisa diperkirakan. Fitur ZFS umumnya bisa dianggap tidak menulis ulang blok yang sudah ada
      Misalnya perubahan konfigurasi juga hanya diterapkan pada data baru
    • Sejujurnya itu catatan yang cukup besar
      Da1 Db1 Dc1 Pa1 Pb1
      Da2 Db2 Dc2 Pa2 Pb2
      Da3 Db3 Dc3 Pa3 Pb3
      ___ ___ ___ Pa4 Pb4
      Di sini ___ adalah ruang kosong. Jika menambahkan satu disk untuk ekspansi, secara logis orang mungkin mengharapkan seperti berikut
      Da1 Db1 Dc1 Da2 Pa1 Pb1
      Db2 Dc2 Da3 Db3 Pa2 Pb2
      Dc3 ___ ___ ___ Pa3 Pb3
      ___ ___ ___ ___ Pa4 Pb4
      Namun sejauh pemahaman saya, yang sebenarnya terjadi adalah ekspansi seperti berikut
      Da1 Db1 Dc1 Dd1 Pa1 Pb1
      Da2 Db2 Dc2 Dd2 Pa2 Pb2
      Da3 Db3 Dc3 Dd3 Pa3 Pb3
      ___ ___ ___ ___ Pa4 Pb4
      Di sini blok Dd1~3 pada dasarnya terbuang. Jadi, meskipun menambahkan disk baru ke array, ruang penyimpanan kosong hanya bertambah 25%
      Misalnya jika awalnya ada total ruang usable 24TB dengan disk 8TB dan ruang kosong sebelum ekspansi 4TB, setelah ekspansi ruang kosong menjadi 5TB
      Saya berharap ada yang mengatakan bahwa saya salah paham. Jika bukan salah paham, ini terlihat seperti implementasi yang cukup tidak berguna

  • Ini kabar besar bagi pengguna ZFS. Mungkin terutama untuk pengguna hobi/rumahan, tetapi tetap besar
    Ekspansi RAIDZ adalah salah satu fitur yang paling banyak diminta selama bertahun-tahun

    • Saya belum terlalu akrab dengan ZFS dan tidak menemukannya di catatan rilis, jadi saya penasaran apakah ekspansi hanya bekerja pada disk dengan ukuran yang sama
      Saya ingin tahu apakah bisa menambahkan disk yang lebih besar atau lebih kecil, atau apakah semua ukuran disk harus sama

  • Ini adalah ekspansi online. Ekspansi itu sendiri sebelumnya juga sudah memungkinkan, tetapi array harus diturunkan
    Berpindah ke drive yang lebih besar juga memungkinkan, tetapi harus menggantinya satu per satu, dan tentu saja kapasitas baru baru didapat setelah semua drive di-upgrade
    Sejauh yang saya tahu, mengecilkan pool masih belum memungkinkan. Jadi jika menambahkan disk ke-6 ke pool berisi 5 drive, Anda tidak bisa kembali lagi ke 5 drive meskipun datanya sangat sedikit

  • Akhirnya!
    Sekarang konfigurasi single vdev yang nyaris gila seperti RAID-Z3 dengan 4 hard disk paling mahal dan berkapasitas paling tinggi yang bisa dibeli saat ini pun menjadi memungkinkan
    Awalnya, karena redundansinya setara 3 disk, efisiensi ruang efektif hanya 25%, tetapi setiap kali kebutuhan ruang meningkat, Anda bisa membeli satu disk dan memperluasnya hingga sekitar 12 disk
    Seiring waktu harga disk turun, dan karena disk ditambahkan pada waktu yang berbeda-beda, probabilitas kegagalannya juga tersebar

    • Benar, tetapi lihat juga komentar saudara
      Meski array diperluas, data lama tidak disimpan dengan lebih efisien
      Untuk mendapatkan rasio parity/data yang baru, Anda harus memaksa data disalin dan menghapus versi lama yang tidak efisien. Misalnya diperlukan alat seperti ini [1]
      Secara pribadi, saya rasa jauh lebih baik membeli konfigurasi RAID-Z yang selesai secara terpisah lalu menambahkan konfigurasi baru, atau mengganti konfigurasi lama disk demi disk
      [1] https://github.com/markusressel/zfs-inplace-rebalancing

  • Saya penasaran bagaimana ZFS dibandingkan dengan btrfs
    Saat ini saya memakai btrfs di server rumah, tetapi sudah beberapa kali mengalami masalah aneh
    Saya sedang mempertimbangkan pindah ke ZFS, tetapi tidak ingin terjebak dalam situasi yang sama

    • Saya pertama kali mencoba btrfs sekitar 15 tahun lalu, pada masa Linux 2.6.33-rc4
      Dalam 3 hari muncul file yang tidak bisa dihapus, jadi saya berhenti memakainya, lalu kemudian menemukan ZFS
      ZFS juga punya beberapa masalah yang tidak terlalu serius, tetapi saat itu saya mahasiswa ilmu komputer, dan dibandingkan masalah yang saya alami di btrfs, masalah itu terlihat sepele sehingga saya pikir bisa diperbaiki
      Selama 18 bulan berikutnya saya menyelesaikan semua masalah yang mengganggu dan mengirim patch ke repositori ZFSOnLinux saat itu; upaya itu membantu membuat ZFS bisa dipakai di lingkungan produksi di Linux
      Sejak itu saya terus memakai ZFS, dan semuanya berjalan baik
      Kalau kondisi btrfs saat itu lebih baik, mungkin saya akan menjadi kontributor btrfs. Namun bukan hanya kondisinya buruk saat itu; setiap kali saya mencobanya lagi untuk penggunaan serius setelahnya, masalah seperti sering munculnya ENOSPC padahal masih ada ruang terus menjadi penghambat
      Sebaliknya, ZFS langsung bekerja. Saya dan banyak orang lain melakukan banyak pekerjaan agar ia bekerja dengan baik
      Perbedaan terbesar adalah ZFS memiliki fondasi yang sangat kuat, berkat fasilitas uji regresi yang sangat baik
      Versi ruang pengguna menjalankan kode secara acak untuk menemukan bug sebelum meledak di lingkungan produksi, dan setiap perubahan yang diusulkan menjalankan serangkaian pengujian untuk menyaring bug
      ZFS juga punya lebih banyak orang yang meninjau perubahan yang diusulkan dibandingkan sistem berkas lain. Para pengembang Btrfs juga sering mengatakan ada perbedaan besar dalam jumlah personel antara kedua sistem berkas itu; seingat saya kira-kira selisihnya 6 kali lipat
      Bagaimanapun, jarang ada orang yang menyesal memakai ZFS, jadi kemungkinan Anda akan menyukainya
    • ZFS sudah dipakai di lingkungan produksi selama hampir 20 tahun
      Menurut dokumentasi BTRFS, BTRFS belum sepenuhnya layak untuk lingkungan produksi: https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid5...
      Beberapa kasus penggunaan sederhana bisa dianggap cukup layak untuk produksi dengan BTRFS, tetapi hasilnya berbeda-beda tergantung lingkungan
    • btrfs punya tujuan yang mirip dengan ZFS, tetapi jauh kurang matang
      Saya memakainya untuk partisi root karena tidak memerlukan DKMS, tetapi masalahnya banyak
      Saya memakainya cukup sederhana, hanya sebagai mirror, tetapi suatu hari ketika salah satu drive dalam array bermasalah, btrfs tidak bertahan dengan baik
      Seingat saya, semuanya di-mount ulang sebagai read-only, dan secara default tidak berjalan dalam mode terdegradasi
      Bahkan mdraid, yang tidak punya fitur seperti checksum, mungkin akan lebih baik daripada ini
      ZFS juga akan menandai array sebagai bermasalah, tetapi tentu saja tetap memungkinkan Anda menggunakannya
      Saya kehilangan kepercayaan karena perilaku default-nya bukan RAID, dalam arti bagian R untuk membaca kembali data pada dasarnya tidak ada
      Setelah pindah ke ZFS, saya tidak punya masalah, dan komunitas serta tool yang bagus juga jauh lebih banyak
    • Saya memakai Btrfs selama beberapa tahun, lalu meninggalkannya beberapa tahun lalu
      Di Btrfs juga pernah terjadi satu-dua hal aneh, tetapi pada akhirnya semuanya bisa dipulihkan
      Secara umum fleksibilitas Btrfs bagus, tetapi dalam kebanyakan kasus saya merasa terlalu lambat
      Sekarang saya memakai ZFS di Arch Linux dan sejauh ini secara umum tidak ada masalah
      Ada juga lebih banyak pengaturan dan cara untuk mengoptimalkan performa
      Satu saran: sebaiknya teliti dan uji ZFS dengan cukup. Ada sedikit kurva belajar, tetapi bagi saya perpindahan itu sepadan

  • Senang melihat adanya bypass ARC untuk performa NVMe
    ZFS cenderung belum bisa memanfaatkan potensi NVMe dengan baik
    Ekspansi online juga bisa menarik
    Saya pernah mencoba memakai ZFS untuk database yang sangat sibuk, tetapi terkena bug fragmentasi parah
    Satu-satunya cara untuk mengembalikan performa tampaknya adalah menyalin data keluar dari volume, menghapus volume, lalu menyalinnya kembali
    Sekarang mungkin kita bisa memperluas zpool, lalu menyalin tablespace di dalam volume yang sama untuk mengurangi fragmentasi

  • Fakta bahwa TrueNAS sudah mendukung fitur ini juga layak dilihat[0]
    Sepertinya mungkin memakai 2.3.0rc3; saya tidak tahu soal stabilitasnya, tetapi ini sangat saya nantikan
    https://www.truenas.com/blog/electric-eel-openzfs-23/

  • Bisa jelaskan kenapa orang memakai sesuatu seperti ZFS untuk penggunaan rumahan?

    • Alasan bagus bagi saya adalah ini
      Checksum: Untuk penggunaan rumahan, kualitas perangkat keras biasanya lebih rendah, jadi justru lebih penting. Ada banyak alasan data yang salah bisa tersimpan, seperti controller yang cacat, kabel yang buruk, hard disk yang disimpan pada suhu lebih tinggi dari yang direkomendasikan, dan ZFS, jika ada redundansi, menanganinya dengan baik secara otomatis
      Snapshot: Sangat berguna untuk membuat backup dan cepat kembali ke versi lama file saat melakukan kesalahan
      Ketenangan pikiran: Dibandingkan alternatifnya, saya merasa ZFS mudah digunakan dan sulit melakukan kesalahan yang berujung pada kehilangan data. Misalnya, saat mengganti drive yang rusak, meski tidak sengaja mencabut drive yang salah sehingga pool tidak bisa digunakan, jika dipasang kembali semuanya berjalan lagi seolah tidak terjadi apa-apa
      Sekarang mdadm mungkin juga sudah berbeda, tetapi saat saya memakainya beberapa tahun lalu, saya selalu cemas akan melakukan kesalahan yang merusak
    • Untuk jawaban yang belum disebut orang lain, ZFS bagus untuk menyimpan game Steam
      Jika mengatur recordsize=1M dan compression=zstd, sering kali bisa menyimpan sekitar 33% lebih banyak game di ruang yang sama
      Seorang teman memakai ZFS untuk menyimpan game Steam di beberapa hard disk. Lalu ia memberi ZFS SSD sebagai L2ARC
      ZFS otomatis men-cache game yang sering dijalankan ke SSD agar loading-nya cepat
      Jika game favorit berubah, ZFS otomatis beradaptasi dan men-cache game tersebut ke SSD
    • Saya memakai zrepl untuk mereplikasi seluruh file system ke NAS lokal setiap 10 menit
      Saat WD_BLACK SN850 tiba-tiba mati [1], ini sudah sekali sangat membantu
      Ini juga memulihkan kode yang hilang karena kesalahan klasik di git
      Kehilangan data karena kesalahan pengguna atau kegagalan satu perangkat semestinya sekarang tidak mungkin lagi terjadi. Kita punya teknologinya
      [1]: https://chromakode.com/post/zfs-recovery-with-zrepl/
    • Ada banyak alasan, tetapi bagi saya alasan besarnya adalah keandalan dan portabilitas
      Tidak ada file system modern lain yang memiliki checksum dan self-healing, serta bisa dibaca dan ditulis di Linux, FreeBSD, Windows, dan macOS
      Snapshot, yaitu boot environment, juga didukung Btrfs. Instalasi Linux saya memakainya agar tidak perlu mengkhawatirkan modul kernel pihak ketiga untuk membaca root file system
      Performanya juga tidak terlalu bagus, dan jika di Linux performa adalah perhatian utama, XFS adalah pilihan yang lebih baik
    • Relatif mudah tetapi kuat
      Sebelumnya saya memakai MDADM + LVM + dm-crypt + ext4, dan itu memang berjalan, tetapi terlalu banyak lapisan sehingga merepotkan
      Snapshot otomatis sangat mudah dan cepat
      Saat file terhapus, mengaksesnya juga mudah, jadi tidak perlu memulihkan seluruh snapshot; cukup cp dari folder tersembunyi .zfs/
      Saya sudah menjalankannya bertahun-tahun dengan 6 disk 8TB. Karena RAIDZ2, hingga 2 disk boleh mati
      Kalau ditanya apakah saya akan memakainya untuk satu disk di desktop, mungkin tidak