Peningkatan fitur deduplikasi OpenZFS, disarankan untuk tidak digunakan sembarangan

 (despairlabs.com)
1 poin oleh GN⁺ 2024-10-31 | 1 komentar | Bagikan ke WhatsApp
  • Fast Dedup di OpenZFS 2.3.0 jauh lebih baik daripada dedup lama, tetapi tetap merupakan fitur yang perlu dipertimbangkan biaya dan syaratnya sebelum diaktifkan begitu saja oleh pengguna umum
  • dedup bekerja dengan cara tidak menulis ulang blok yang sudah tersimpan dan hanya menambah referensi, sehingga semua jalur penulisan dan pelepasan mendapat biaya lookup dan pembaruan dedup table
  • Metode lama memiliki beban memori dan IO yang besar karena amplifikasi read-modify-write pada tabel berbasis ZAP, live entry list yang tidak bisa direklamasi selama transaksi, dan unique entry yang tidak memberi manfaat
  • Fast Dedup mengurangi live entry dari 424 byte menjadi 216 byte, serta memberi operator kendali biaya yang lebih baik lewat dedup log, flush bertahap, zpool ddtprune, dedup_table_quota, prefetch DDT, dan kstats
  • Pada workload umum, blok yang benar-benar duplikat bisa sangat sedikit, dan BRT/block cloning di OpenZFS 2.2 dapat memberi penghematan serupa dengan biaya lebih rendah, sehingga dedup layak dipakai dengan hati-hati hanya saat data duplikat sangat besar dan tidak ada alternatif zero-copy

Cara kerja dasar dedup OpenZFS

  • Deduplikasi (dedup) adalah fitur OpenZFS yang, sebelum menulis data ke disk, akan melewatkan penulisan baru jika data yang sama sudah ada, lalu menambahkan referensi ke salinan yang sudah ada
  • Bagian yang sulit adalah informasi untuk cepat mengetahui “apakah data itu sudah ada di disk” dan “ada di mana” harus terus disimpan dan dicari
  • Struktur yang menyimpan informasi ini adalah dedup table
    • Secara konsep, ini adalah hash table dengan checksum data sebagai key, dan lokasi disk serta jumlah referensi (refcount) sebagai value
    • Ini bukan data pengguna, melainkan data struktural pool yang disimpan sebagai bagian dari metadata pool

Biaya yang menempel pada jalur tulis dan pelepasan

  • Saat dedup dimatikan, OpenZFS mengambil alokasi ruang dari metaslab allocator, memasukkan DVA yang dikembalikan ke block pointer, lalu menulis data
  • Saat dedup diaktifkan, checksum dicari dulu di dedup table
    • Jika tidak ada entri, ruang baru dialokasikan, data ditulis, lalu dibuat dedup entry baru dengan refcount 1
    • Jika ada entri, DVA yang sudah ada disalin ke block pointer, IO tulis dianggap selesai, lalu refcount dinaikkan
  • Pada blok yang dialokasikan melalui dedup, flag D disetel pada block pointer
    • Saat dilepas, jika ada flag D, dedup table dicari lagi dan refcount diturunkan
    • Jika refcount menjadi 0, dedup entry dihapus dan ruang fisik benar-benar dilepas
  • Karena semua operasi tulis dan pelepasan melewati lookup dan pembaruan dedup table, dedup hanya berguna bila penghematan ruang dan IO nyata lebih besar daripada overhead pengelolaan tabel

Mengapa dedup lama buruk

  • Amplifikasi dedup table berbasis ZAP

    • dedup table lama menggunakan ZAP, objek hash table on-disk standar OpenZFS
    • ZAP adalah struktur umum yang juga dipakai untuk direktori, daftar atribut, dan manajemen internal, tetapi kurang cocok untuk menyimpan dedup entry
    • dedup entry biasa terdiri dari key 40 byte dan value sekitar 64 byte setelah kompresi, sehingga satu blok ZAP 32K dapat memuat sekitar 188 entri biasa
    • Karena OpenZFS tidak melakukan partial block write maupun overwrite in-place, memperbarui satu entri pun mengharuskan seluruh blok ZAP dibaca, dimodifikasi, lalu ditulis ulang sebagai blok baru
    • Key checksum harus tahan benturan, sehingga peluang dua entri acak ditempatkan berdekatan dalam blok ZAP yang sama kecil, dan peluang banyak pembaruan dalam satu transaksi terkumpul pada blok yang sama juga rendah
    • Jika RAM cukup sehingga ARC dapat terus menahan dedup table, biaya baca berkurang, tetapi inilah yang melahirkan anjuran lama bahwa dedup membutuhkan memori besar
    • vdev class dedup dapat sedikit mengurangi kebutuhan memori dengan menambahkan dedicated dedup vdev yang cukup besar dan cepat, tetapi pada skala saat dedup benar-benar berarti, perangkat itu tetap harus cukup besar untuk menampung keseluruhan tabel dan cukup cepat

  • Penggunaan memori live entry list

    • OpenZFS menyimpan dedup entry yang dibuat atau dimodifikasi selama transaksi dalam live entry list di memori
    • Struktur ini mencegah situasi saat data yang sama ditulis beberapa kali pada saat yang sama dan tiap thread penulis mengira entri itu belum ada di dedup table sehingga semuanya menulis salinan baru
    • lookup lebih dulu memeriksa live entry list
      • Jika entri ada, refcount dinaikkan
      • Jika tidak ada, dibuat live entry berstatus “in progress”, entri sebenarnya dibaca dari ZAP, lalu status diubah menjadi “ready”
      • Thread penulis lain yang mengakses bersamaan akan menunggu sampai status menjadi ready
    • Saat transaksi selesai, live entry list diiterasi untuk menerapkan isi terkait ke dedup ZAP
    • live entry lama berukuran 424 byte per entri, dan memori ini bukan ARC melainkan kernel slab memory sehingga tidak bisa direklamasi saat sistem mengalami tekanan memori
    • live entry list dikosongkan setiap transaksi, tetapi jika satu transaksi menulis banyak data berbeda, puncaknya bisa menjadi besar

  • unique entry membengkakkan tabel

    • dedup melacak semua blok yang tersimpan di disk, tetapi manfaat nyata hanya muncul saat refcount lebih besar dari 1
    • unique entry dengan refcount 1 pada dasarnya adalah biaya untuk menunggu kemungkinan data yang sama ditulis lagi suatu saat nanti
    • dedup dilakukan per blok setelah enkripsi dan kompresi
    • Bahkan jika data sumbernya sama, metode kompresi, kunci enkripsi, hingga alignment di dalam file juga harus cocok agar dianggap blok yang sama
    • Pada workload tujuan umum, jumlah blok yang “benar-benar sama” sering sedikit, sehingga biaya dedup mudah melampaui manfaatnya

Peningkatan pada Fast Dedup

  • Penyusutan live entry

    • Fast Dedup pertama-tama mengurangi jejak memori live entry list
    • Flag bertipe angka besar pada ddt_entry_t diubah menjadi bitfield, dan field sinkronisasi disederhanakan
    • Status 40 byte yang hanya dipakai saat pertama kali menulis blok data yang didedup atau saat perlu repair write dipisahkan menjadi objek IO state tersendiri
    • Nilai dedup entry lama berukuran 256 byte karena memuat empat physical entry
    • Tiap physical entry berisi tiga DVA 128-bit, refcount, dan birth transaction id
    • Entri keempat adalah jejak dari fitur lama dedupditto; OpenZFS modern hanya mendukung pembacaan dan tidak lagi menulisnya
    • Fast Dedup tidak lagi mempertahankan variant lama sebagai entri terpisah saat copies= berubah dan butuh lebih banyak DVA, melainkan hanya mengalokasikan salinan tambahan yang diperlukan dan menambahkannya ke dedup entry yang ada
    • Nilai entry pada Fast Dedup table baru menyusut dari 256 byte menjadi 72 byte
    • Satu entri dalam live list turun dari 424 byte menjadi 216 byte

  • Pengenalan dedup log

    • Cara lama langsung menerapkan live entry list ke dedup ZAP saat transaksi berakhir, sehingga biaya pembaruan tingkat blok tetap muncul walaupun 187 entri di sekitarnya kebanyakan tidak relevan
    • Fast Dedup menambahkan dedup log berdasarkan pengamatan bahwa blok yang baru dibuat atau baru terdeduplikasi lebih mungkin kembali dideduplikasi atau dilepas
    • Di akhir transaksi, perubahan live entry tidak langsung ditulis ke ZAP melainkan dicatat ke log
      • log on-disk dibutuhkan untuk crash safety
      • log in-memory dipertahankan untuk lookup cepat
    • Urutan lookup menjadi live entry list, lalu in-memory log, lalu dedup ZAP
    • log on-disk digunakan untuk memulihkan in-memory log saat pool di-import

  • Flush log bertahap

    • Jika seperti metode awal log di-flush ke ZAP sekaligus saat terlalu besar, beberapa ribu entri saja dapat menimbulkan pause panjang
    • Fast Dedup menggunakan incremental flushing, yang menerapkan sebagian log ke ZAP pada setiap transaksi
    • Jumlah flush disesuaikan dengan waktu yang benar-benar dipakai untuk IO
      • Saat sibuk, yang ditulis lebih sedikit; saat sepi, lebih banyak
      • Jika in-memory log membesar dan menimbulkan tekanan memori, flush dapat dipercepat
    • Untuk menjaga on-disk log tetap append-only sekaligus dapat dikosongkan tanpa penghentian total, digunakan dua log
      • Satu sebagai active log untuk menerima perubahan baru
      • Satu lagi sebagai flushing log untuk diterapkan ke ZAP
      • Saat flushing log kosong, on-disk log di-zero-kan dan peran kedua log ditukar
    • Pada pool scan seperti scrub atau resilver, karena dedup log tidak memiliki konsep posisi stabil, flush log dipercepat saat ada permintaan scan agar semuanya diterapkan dulu ke dedup ZAP, lalu scan dilakukan dengan cara lama

Pengelolaan unique entry dan fitur operasional

  • zpool ddtprune menghapus sebagian unique entry dari dedup table pool
    • Dapat ditentukan berdasarkan age atau percentage
    • Mode age sangat cocok untuk workload yang kemungkinan data yang baru dipakai akan kembali dideduplikasi lebih tinggi
  • Jika blok yang dedup entry-nya dihapus lewat pruning kemudian disalin lagi di masa depan, blok itu tidak akan dideduplikasi dengan blok lama dan akan dialokasikan sebagai blok baru
    • Namun, jika unique block lama tiba-tiba disalin berkali-kali, tetap bisa muncul banyak referensi ke satu blok baru
  • Properti pool dedup_table_quota membatasi ukuran maksimum dedup table
    • Jika pembuatan entri baru melewati batas, entri tidak dibuat dan penulisan diproses sebagai write biasa non-dedup
    • Ini juga bisa dipakai agar dedicated dedup device yang penuh tidak meluber ke perangkat utama
  • zpool prefetch -t ddt memuat dedup table ke ARC lebih awal
    • Ini dapat membantu performa segera setelah pool di-import
    • Bahkan pada Fast Dedup, ini tetap berguna karena lookup entri yang tidak ada di log dan proses flush tetap perlu mengakses ZAP
  • kstats dan tuneable baru juga ditambahkan
    • Linux: /proc/spl/kstat/zfs/<pool>/ddt_stats_<checksum>
    • FreeBSD: kstat.zfs.<pool>.misc.ddt_stats_<checksum>
    • Linux tuneable: /sys/modules/zfs/parameters/zfs_dedup_log_*
    • FreeBSD tuneable: vfs.zfs.dedup.log_*
  • Alat lama yang sadar dedup seperti zpool status -D, zdb -D, dan zdb -S juga diperbarui agar memahami struktur baru

Kompatibilitas dengan dedup table lama

  • Sebagian besar Fast Dedup memerlukan perubahan format on-disk, sehingga tidak bisa langsung diterapkan pada dedup table lama
  • Pada table lama, fitur yang tidak membutuhkan perubahan format on-disk tetap dapat berjalan
    • dedup_table_quota
    • zpool prefetch -t ddt
    • lookup dan hit count ddt_stats_*
    • ZAP shrink
  • Membuat dedup log bekerja juga pada table tradisional masih merupakan pekerjaan yang relatif straightforward
    • Namun manfaat entry live/log yang lebih kecil tidak akan didapat
  • zpool ddtprune pada table lama relatif mudah ditambahkan hanya untuk mode “percentage of uniques”
    • Mode age tidak mungkin karena membutuhkan data dari format entry baru
  • Saat ini belum ada fitur untuk mengonversi table lama ke format baru
    • Untuk kasus sederhana yang copies=-nya belum pernah berubah, pendekatan membuat ZAP baru lalu mengonversi dan menyalin entri lama dimungkinkan
    • Konversi online rumit karena perlu lookup atau penulisan bersamaan ke old/new ZAP
    • Konversi offline lebih mudah tetapi mengharuskan pool dibawa offline
    • Jika ada beberapa variant yang memiliki refcount akibat perubahan copies=, konversi penuh mungkin tidak memungkinkan
  • Mengirim dataset yang sudah dideduplikasi ke pool lain yang mendukung dedup baru tetap bisa dilakukan

“Sudah lebih baik, tapi kenapa tetap jangan diaktifkan?”

  • Fast Dedup memang mengurangi overhead dibanding sebelumnya dan bisa berguna pada lebih banyak situasi marginal
  • Namun dedup tetap merupakan masalah keseimbangan antara throughput IO, penggunaan memori, dan ukuran dedup table
  • Pada workload tujuan umum, blok yang bisa dideduplikasi bisa sangat jarang
  • Hasil simulasi DDT zdb -S pada contoh laptop pool menunjukkan hampir tidak ada manfaat dedup
    • Dari 11,7 juta entri, mayoritas adalah unique entry dengan refcount 1
    • Jumlah entri yang benar-benar bisa dideduplikasi hanya setingkat galat pembulatan dari keseluruhan
    • Nilainya muncul sebagai dedup = 1.00
  • Dalam kasus seperti ini, mengaktifkan dedup hanya menambah tekanan IO dan memori tanpa hampir memberi hasil apa pun

Kasus saat BRT/block cloning lebih baik

  • Sejak OpenZFS 2.2, ada BRT, yaitu block cloning atau reflink
  • dedup table adalah struktur untuk mengetahui “apakah data ini sudah ada di disk” tanpa konteks
  • Pada sistem modern, kadang operasi salin dapat disampaikan ke storage stack sebagai tindakan penyalinan
    • copy_file_range() pada filesystem Linux dan FreeBSD
    • copyfile() di macOS
    • FSCTL_SRV_COPYCHUNK di Windows
    • Fitur serupa juga ada di NFS, CIFS, driver block device OS, SCSI EXTENDED COPY, NVMe Copy, dan lainnya
  • Jika program klien dan lapisan perantara meneruskan sinyal copy offload, OpenZFS cukup menaikkan refcount di BRT
  • BRT tidak menimbulkan biaya jika blok tidak di-clone, dan bila di-clone, ukuran entri hanya 16 byte
  • Pada pool contoh, BRT menunjukkan used 292M; saved 309M; ratio 2.05x
  • Penghematan raw-nya sedikit lebih kecil namun mirip dengan simulasi dedup, tetapi tanpa biaya besar untuk melacak seluruh blok yang tidak di-clone

Kriteria penilaian praktis

  • Fast Dedup memperbaiki ketiga sumbu dedup tradisional: throughput IO, penggunaan memori, dan ukuran dedup table
  • Biaya yang bisa menjadi bencana saat gagal juga berkurang, dan operator kini punya alat untuk membatasi serta merapikan table
  • Meski begitu, syarat agar benar-benar menguntungkan tetap jelas
    • Skala data harus sangat besar
    • Data yang sama harus banyak disalin
    • Alternatif zero-copy lain di OpenZFS seperti block cloning atau snapshot clone tidak boleh tersedia
  • Jika klien bisa memberi sinyal yang jelas bahwa operasi tersebut adalah “tolong salin ini”, maka block cloning bisa memberi manfaat besar dengan biaya yang lebih rendah

Bacaan terkait

1 komentar

 
GN⁺ 2024-10-31
Komentar Hacker News

  • Akan bagus jika ada deduplikasi offline, atau deduplikasi tertunda yang tidak harus menurunkan pool sepenuhnya, tetapi tidak langsung dijalankan
    Jika deduplikasi diaktifkan, setiap operasi tulis dan free harus melakukan lookup dan penulisan ke tabel deduplikasi; dalam kebanyakan kasus ini terasa seperti pendekatan yang keliru. Saat menulis data, kita ingin proses selesai secepat mungkin meskipun memakai lebih banyak ruang disk, dan itulah sebabnya kita tidak menyimpan file yang sedang dikerjakan di dalam arsip 7zip. Akan lebih baik jika nanti, saat sistem sedang idle, ZFS mencari data duplikat dan merebut kembali ruang dengan sesuatu seperti BRT; tampaknya ini juga bisa dijadikan bagian dari proses scrub biasa

    • Deduplikasi tertunda/offline memerlukan penulisan ulang block pointer, tetapi karena ZFS bukan sistem CAS sejati, sepertinya akan sulit mendapatkan penulisan ulang BP yang benar di masa depan
      Karena lokasi fisik ikut di-hash ke dalam pohon hash Merkle, untuk memindahkan lokasi fisik harus menulis ulang semua node internal sampai ke node yang ingin diubah, sehingga biayanya terlalu besar. Desain yang lebih baik seharusnya membagi semua node yang memiliki block pointer menjadi bagian yang hanya berisi logical block pointer dan ikut di-hash ke dalam tree, serta bagian yang hanya menyimpan lokasi fisik yang sesuai dengan pointer logis itu seperti cache tetapi tidak di-hash ke dalam Merkle tree. Dengan begitu, penulisan ulang BP hanya perlu menulis ulang blok yang bukan bagian dari Merkle tree. Dengan struktur saat ini, sulit mendapatkan fungsi yang diinginkan di ZFS, tetapi mungkin ada workaround: jika saat baca terjadi ketidakcocokan hash, cari blok di tabel deduplikasi menggunakan hash pointer lalu alokasikan ulang blok yang sudah dideduplikasi. Biayanya kira-kira satu pembacaan yang sia-sia, jadi tidak terlalu buruk, tetapi jika penulisan ulang BP tidak mungkin, biasanya tambalan seperti ini muncul
    • Pendekatan ini sama dengan metodologi deduplikasi Windows. Saya cukup sering memakainya, dan jika perangkat kerasnya memadai, umumnya memuaskan
      Memang banyak memakan RAM dan I/O, tetapi “groveler” bisa dijadwalkan dan dibatasi. Namun, pada era Windows 2012 R2, saya pernah mengalami korupsi yang memakan data karena bug
    • Ini juga bisa dilakukan dengan pendeteksi file duplikat offline
      Contohnya jdupes atau duperemove. Saya sudah mengirim PR ke sisi ZFS dan duperemove agar mendukung system call yang dibutuhkan. Review di sisi ZFS memakan waktu lama, dan saya baru sadar bahwa saya benar-benar lupa menuntaskannya, jadi harus saya urus lagi
    • Kemampuan untuk mengubah snapshot yang sudah ada di ZFS sangat terbatas, bahkan jika caranya tetap mempertahankan data sepenuhnya. Jadi memang akan bagus jika ada fungsi seperti itu, tetapi jika menunggu Block Pointer Rewrite, mungkin sudah mati sejak lama
    • Hal bagus dari deduplikasi inline adalah jika hash blok sudah ada, blok itu tidak perlu benar-benar ditulis
      Dalam berbagai situasi, ini bisa sangat mengurangi I/O tulis. Pada array storage deduplikasi, ada juga ekstensi yang ketika menyalin file antara dua VM, data sebenarnya tidak disalin dan hanya reference counter blok asal yang dinaikkan. Dari sisi sistem operasi, ini terlihat seperti kecepatan tulis TB/s yang tidak masuk akal, dan itu cukup keren

  • Klaim bahwa “masalah mendasar deduplikasi tradisional adalah overhead seperti ini terlalu besar sehingga sulit ditebus kecuali pada workload yang jarang dan spesifik” terdengar cukup aneh
    Saya pernah menangani array Pure dan Dell/EMC, dan pada workload VMWare biasanya ada penghematan minimal 3:1 lewat deduplikasi/kompresi. Cara menyimpan hanya satu salinan base image VM bekerja sangat baik. Pada server syslog pun deduplikasi/kompresi efektif, dan saya pernah melihat penghematan 6:1. Efektivitas deduplikasi sangat bergantung pada ukuran blok yang di-hash; makin kecil makin baik. Semakin kecil bloknya, probabilitas munculnya blok yang cocok meningkat cepat, dan berdasarkan pengalaman ukuran blok yang saya sukai adalah 4KB

    • Image VM adalah informasi dengan redundansi sangat tinggi, seperti drive C pada image Windows Server yang hampir sama, sedangkan artikel aslinya memakai isi laptop penulis sebagai contoh
      Selain itu, tampaknya ia mencampuradukkan dua fungsi berbeda: kompresi dan deduplikasi. Di ZFS, kompresi bisa diaktifkan pada pool dan hampir selalu bernilai, sementara deduplikasi bisa dibiarkan mati
    • Base image VM termasuk workload yang jarang dan spesifik, dan merupakan salah satu dari sedikit kasus deduplikasi masuk akal
      Namun jika meng-host VM di atas filesystem ZFS, kemungkinan besar Anda memakai strategi yang lebih baik seperti clone blok atau filesystem. Tidak melakukan itu berarti membuang salah satu pembeda utama ZFS di lingkungan tersebut. Pada file server umum atau penggunaan desktop/laptop pribadi, biasanya blok duplikat sangat sedikit sehingga overhead-nya tidak sepadan. Backup bisa cocok atau tidak, tergantung cara implementasi dan apakah dienkripsi sebelum lapisan filesystem. Kompresi adalah cerita yang sama sekali berbeda, dan praktik terbaik ZFS saat ini adalah mengaktifkannya secara default untuk hampir semua workload. Saat ini biaya CPU hampir tidak layak disebut, dan terlepas dari penghematan kapasitas storage, pengurangan I/O bisa cukup besar. Untuk penyimpanan log umum, berdasarkan pengalaman penghematan yang jauh lebih baik dari 6:1 pun mungkin
    • Saya belum mencobanya sendiri, tetapi angka yang sering dikutip untuk deduplikasi ZFS lama adalah perlu RAM 5GB per 1TB disk
      Jika sekarang 1TB disk sekitar 15 dolar dan 5GB RAM server sekitar 25 dolar, maka hanya untuk mencapai titik impas pun perlu rasio deduplikasi 3:1. Jika datanya sangat cocok, mungkin bisa bertahan dengan 1GB per TB, tetapi jika kurang beruntung, 5GB pun bisa tidak cukup. Karena itu tulisan tersebut mengatakan deduplikasi ZFS punya sweet spot kecil yang datanya harus benar-benar pas, dan itulah alasan kebanyakan orang tidak memedulikannya. Filesystem lain biasanya lebih memilih deduplikasi offline yang ekonominya lebih baik
    • VM memang diketahui mendapat manfaat dari deduplikasi, jadi di sisi itu bisa efektif. Namun ZFS bukan hanya SAN enterprise, melainkan filesystem serbaguna, sehingga banyak pengguna ZFS tidak menjalankan VM
      Jika dilihat lebih rinci, ungkapan bahwa deduplikasi/kompresi bekerja baik pada syslog kurang tepat karena deduplikasi dan kompresi bukan hal yang sama. Di dunia storage enterprise keduanya sering dipaketkan bersama, tetapi log mungkin mendapat manfaat dari kompresi, bukan deduplikasi, dan ZFS sejak awal sudah memiliki kompresi
    • Tidak menyimpan banyak deep copy dari base image VM jelas masuk akal, tetapi di ZFS deduplikasi bukan cara yang tepat
      Sebagai gantinya, jika base image di-clone, sebelum ada perubahan hampir tidak memakan ruang. Ini berkat sifat copy-on-write ZFS. Deduplikasi ZFS adalah fitur untuk mencari salinan yang sudah ada dari data yang ditulis ke volume. Untuk beberapa penggunaan seperti penyimpanan image container, ini bisa cukup masuk akal, tetapi jika sejak awal sudah tahu bahwa suatu dataset adalah clone dari yang lain, pendekatan itu sangat tidak efisien

  • Dulu deduplikasi ZFS digunakan secara luas dan memberikan manfaat besar. Kasus spesifiknya adalah storage untuk klaster VMWare, dengan ratusan VM Linux dan Windows yang isinya sebagian besar sama. Ini cerita dari era sebelum Docker

    • Di sini terlihat beberapa contoh penggunaan deduplikasi untuk VM, tetapi sepertinya ini jauh lebih efisien jika diimplementasikan di hypervisor daripada di filesystem
    • Setuju. Baru-baru ini saya mendapat laptop kerja baru dengan zfs “experimental” Ubuntu, dan memakai deduplikasi pada nix store benar-benar sangat membantu

  • Saya sangat menantikan deduplikasi cepat. Selama bertahun-tahun saya ingin memakai deduplikasi ZFS untuk data ArchiveBox, dan berkat deduplikasi cepat, sepertinya akhirnya akan memungkinkan untuk mengarsipkan jutaan URL dalam satu koleksi dan membiarkan filesystem menangani kompresi keseluruhan
    Data arsip berisi hal-hal seperti jquery.min.js, bootstrap.min.css, dan gambar logo yang berulang di ribuan snapshot. Alat lain mengompresi dalam satu kali crawl untuk membuat file wacz atau warc.gz, tetapi sejauh ini sepertinya belum ada alat yang mencoba kompresi melintasi seluruh database dari semua snapshot yang pernah diambil. Saya juga penasaran apakah ada yang pernah mencoba pendekatan deduplikasi probabilistik seperti Bloom filter agar tidak perlu menyimpan seluruh tabel hash deduplikasi. Misalnya mengelompokkan sekitar 100 hash blok ke dalam bucket, lalu menyimpan representasi super-terkompresi di Bloom filter. Saat menulis, hash blok yang akan ditulis dicek di Bloom filter; jika terdeteksi kemungkinan hit deduplikasi, 100 blok dalam bucket tersebut dipindai langsung untuk mencari hash yang sama. Secara teori, bisa juga ada lapisan Bloom filter dengan resolusi berbeda, dan saat tekanan memori tinggi, filter beresolusi tinggi diturunkan secara dinamis ke disk. Jika akurasi Bloom filter dijadikan parameter yang dapat disetel, pengguna bisa memilih preferensi antara waktu CPU/overhead dan rasio byte yang dihemat

    • Bahkan dengan perubahan ini, deduplikasi ZFS tetap berbasis penyelarasan blok, jadi jika aset web yang berulang tidak selalu berada pada offset yang sama di dalam arsip WARC, hasilnya kemungkinan tidak akan cocok
      dm-vdo juga berperilaku sama. Sebagai gantinya, mungkin lebih baik memakai solid compression yang melihat rentang panjang, mengekstrak file WARC menjadi struktur yang setara dengan direktori, atau memakai sistem FUSE berbasis content-defined chunking jika ada. Mungkin Seafile seperti itu
    • Saya memahami kasus penggunaannya, tetapi dalam kebanyakan kasus, khususnya yang ini, sepertinya jauh lebih baik diimplementasikan di sisi klien
      Jika melihat standar WARC, sudah ada deduplikasi berbasis hash dan mekanisme memakai pointer setelah penyimpanan pertama. Jadi ini justru contoh yang tepat di mana deduplikasi pada lapisan filesystem tidak terlalu bagus
    • Kasus penggunaannya agak berbeda, tetapi kalau belum tahu zbackup, sepertinya Anda akan menyukainya

  • Saya penasaran mengapa begitu sulit membuat ini berjalan dengan baik sambil mengurangi penggunaan RAM. Appliance storage komersial sudah bisa melakukannya setidaknya sejak sekitar 10 tahun lalu, bahkan pada sistem dengan RAM yang “sedikit” dibandingkan kapasitas disk yang terpasang
    Bukankah cukup menyimpan fingerprint di database lalu memindainya pada malam hari sambil memperbaiki pointer blok?

    • “Memperbaiki pointer blok” itulah alasannya. Karena berbagai alasan, ZFS tidak memiliki kemampuan penulisan ulang pointer blok
      Ini fitur yang sudah lama diminta, dan jika memungkinkan, defragmentasi juga bisa dilakukan. Saya pernah berpikir bahwa memakai indireksi pointer blok seperti virtual memory mungkin bisa menyelesaikannya dengan sedikit biaya performa, tetapi saya bukan pengembang ZFS, jadi pasti ada hal yang saya lewatkan. http://eworldproblems.mbaynton.com/posts/2014/zfs-block-poin... / https://github.com/openzfs/zfs/issues/3582
    • Memperbaiki pointer blok justru satu hal yang ZFS tidak ingin lakukan
    • Ada juga cara memakai DragonFlyBSD dan Hammer2. Hammer2 mendukung deduplikasi online maupun offline dan dalam banyak hal sangat mirip dengan ZFS
      Kekurangan besarnya adalah tidak ada protokol transfer file yang memakai RDMA. Saya dengar ada juga branch eksperimental untuk menjalankan Hammer2 di FreeBSD. Namun FreeBSD juga tidak memiliki dukungan RDMA. Di FreeBSD 15, Chelsio mensponsori dukungan target dan initiator NVMe-oF, tetapi sepertinya hanya untuk TCP

  • Cukup pakai cp --reflink=auto
    Anda bisa mendapatkan deduplikasi tingkat file. Perintah ini melakukan penyalinan ringan; seperti klon ZFS pada tingkat file, blok data hanya disalin saat dimodifikasi. Ini bukan hard link, melainkan salinan. Cara yang sama seharusnya bekerja pada filesystem transaksional copy-on-write lain yang mendukung reflink

  • Saya benar-benar ingin memakai ZFS, tetapi semua data tentu saja harus dienkripsi. Namun penggunaannya ternyata jauh lebih rumit dari perkiraan, dan yang mengejutkan, saat keadaan menjadi rumit, banyak orang akhirnya tidak mengenkripsi datanya sama sekali
    Bahkan Proxmox, yang di situsnya memakai label “Enterprise”, saya kira akan mendukung enkripsi pada instalasi default, tetapi jika ingin memakainya bersama enkripsi, Anda kehilangan fitur penting. Issue tracker juga wajib dicek. Ada beberapa hal mengejutkan yang tidak saya sangka ada di filesystem operasional

    • Cara terbaik mengenkripsi ZFS adalah menaruh ZFS yang tidak terenkripsi di atas volume terenkripsi, misalnya volume LUKS. “Enkripsi” ZFS membuat terlalu banyak hal tetap dalam plaintext sehingga terasa mengkhawatirkan

  • Saya berharap ada API yang benar-benar berbeda untuk filesystem. Permukaan API filesystem di semua sistem operasi adalah kekacauan total yang terjebak oleh kompatibilitas ke belakang

    • Secara internal, ZFS pada dasarnya adalah object store. Pernah ada upaya untuk mengeksposnya sebagai API object store, tetapi sayangnya tampaknya tidak berlanjut ke mana-mana
      Saya mencoba mencari presentasinya tetapi gagal. Saya kira pernah melihatnya di Developer Summit, tetapi mungkin bukan
    • Mengapa kacau, dan bisa diganti dengan apa? Apakah API ala AWS S3 akan menjadi perbaikan?

  • Lupakan deduplikasi; memakai kompresi ZFS jauh lebih hemat biaya

    • Pengecualiannya adalah jika dataset sudah berupa file media yang sangat terkompresi
      Biasanya, bahkan saat menjalankan rsync, kompresi sering dimatikan untuk file video besar. Kompresi kurang efektif, atau bahkan tidak berguna, untuk penyimpanan maupun transfer, tetapi tetap memakan RAM dan CPU. Deduplikasi bagus untuk image OS Virtual Machine, karena sebagian besar biaya storage berasal dari base image yang berulang

  • Deduplikasi serbaguna secara teori tampak bagus, tetapi dalam praktiknya sering kali tidak berjalan mulus. IPFS menggunakan potongan berukuran variabel dan rolling hash untuk menduplikasi data seperti rsync, tetapi dalam praktiknya tidak membuat perbedaan dan hanya menambah kompleksitas yang tidak perlu