OpenZFS dedup फीचर में सुधार, इस्तेमाल से बचने की सलाह

 (despairlabs.com)
1 पॉइंट द्वारा GN⁺ 2024-10-31 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • OpenZFS 2.3.0 का Fast Dedup मौजूदा dedup से काफी बेहतर है, लेकिन आम यूज़र के लिए इसे default की तरह ऑन करने से पहले इसकी लागत और शर्तों को अभी भी तौलना ज़रूरी है
  • dedup पहले से stored blocks को दोबारा लिखने के बजाय सिर्फ़ references बढ़ाता है, इसलिए हर write और free path में dedup table lookup और update की लागत जुड़ती है
  • पुराने तरीके में ZAP-based table की read-modify-write amplification, transaction के दौरान reclaim न हो सकने वाली live entry list, और बिना लाभ वाली unique entries की वजह से memory और IO पर भारी बोझ पड़ता था
  • Fast Dedup live entry को 424 bytes से घटाकर 216 bytes करता है, और dedup log, incremental flush, zpool ddtprune, dedup_table_quota, DDT prefetch और kstats के ज़रिए operators को लागत पर बेहतर नियंत्रण देता है
  • सामान्य workloads में वास्तविक duplicate blocks कम हो सकते हैं, और OpenZFS 2.2 का BRT/block cloning कम लागत में मिलती-जुलती बचत देता है, इसलिए dedup का इस्तेमाल केवल तब सावधानी से करना चाहिए जब बड़े पैमाने पर duplicate data हो और zero-copy विकल्प उपलब्ध न हों

OpenZFS dedup का मूल व्यवहार

  • deduplication(dedup) OpenZFS का वह feature है जो data को disk पर लिखने से पहले, अगर वही data पहले से मौजूद हो, तो नई write को छोड़कर मौजूदा copy में reference जोड़ देता है
  • कठिन हिस्सा यह है कि “क्या यह पहले से disk पर है” और “कहाँ है” जल्दी पता करने के लिए जानकारी को लगातार store और lookup करना पड़ता है
  • इस जानकारी को रखने वाली structure dedup table है
    • अवधारणात्मक रूप से यह एक hash table है जिसमें data checksum key होता है, और disk location व reference count(refcount) value होते हैं
    • यह user data नहीं, बल्कि pool metadata के हिस्से के रूप में stored structural pool data है

write और free paths में जुड़ने वाली लागत

  • अगर dedup बंद है, तो OpenZFS metaslab allocator से space allocate करता है, लौटाए गए DVA को block pointer में डालता है और data लिखता है
  • अगर dedup चालू है, तो पहले checksum को dedup table में lookup किया जाता है
    • entry नहीं हो तो नया space allocate कर data लिखा जाता है, फिर refcount 1 वाली नई dedup entry बनाई जाती है
    • entry हो तो मौजूदा DVA को block pointer में copy किया जाता है, write IO को complete माना जाता है, और refcount बढ़ाया जाता है
  • dedup से allocated blocks में block pointer पर D flag set होता है
    • free करते समय D flag हो तो dedup table को फिर lookup कर refcount घटाया जाता है
    • refcount 0 हो जाए तो dedup entry delete की जाती है और वास्तविक space free किया जाता है
  • चूँकि हर write और free dedup table lookup/update से गुजरता है, dedup तभी उपयोगी है जब table management overhead से वास्तविक space/IO saving अधिक हो

पुराना dedup खराब क्यों था

  • ZAP-based dedup table की amplification

    • पुराना dedup table OpenZFS के standard on-disk hash table object ZAP का इस्तेमाल करता है
    • ZAP directory, attribute lists और internal management में भी इस्तेमाल होने वाली general-purpose structure है, लेकिन dedup entry storage के लिए बहुत उपयुक्त नहीं है
    • आम dedup entry में 40-byte key और compression के बाद लगभग 64-byte value होती है, और एक 32K ZAP block में लगभग 188 सामान्य entries आती हैं
    • OpenZFS partial block write और in-place overwrite नहीं करता, इसलिए एक entry update करने पर भी पूरे ZAP block को पढ़ना, modify करना और फिर नए block के रूप में लिखना पड़ता है
    • checksum key को collision-resistant होना चाहिए, इसलिए किसी भी दो entries के एक ही ZAP block में पास-पास रखे जाने की संभावना कम होती है, और transaction के भीतर कई updates के एक ही block में इकट्ठा होने की संभावना भी कम होती है
    • अगर RAM पर्याप्त हो और ARC dedup table को लगातार रखे, तो read cost कम होती है, लेकिन इसी कारण dedup के लिए बहुत memory चाहिए—यह पुरानी सलाह बनी
    • dedup vdev class पर्याप्त बड़ा और तेज dedicated dedup vdev जोड़कर memory requirement थोड़ी कम कर सकता है, लेकिन जिस scale पर dedup मायने रखता है, वहाँ पूरी table को रखने लायक size और पर्याप्त speed चाहिए

  • live entry list की memory usage

    • OpenZFS transaction के दौरान बनाई/modify की गई dedup entries को memory की live entry list में रखता है
    • जब वही data एक ही समय पर कई बार लिखा जाता है, तब हर write thread यह न माने कि वह dedup table में अभी नहीं है और सब उसे नया लिख दें—इसी को रोकने के लिए यह structure है
    • lookup पहले live entry list check करता है
      • संबंधित entry हो तो refcount बढ़ाता है
      • न हो तो “in progress” state की live entry बनाता है, ZAP से वास्तविक entry पढ़ता है और उसे “ready” में बदलता है
      • उसी समय access करने वाले दूसरे write threads ready होने तक wait करते हैं
    • transaction खत्म होने पर live entry list को iterate कर संबंधित contents को dedup ZAP में reflect किया जाता है
    • पुरानी live entry प्रति entry 424 bytes थी, और यह memory ARC नहीं बल्कि kernel slab memory थी, इसलिए system memory pressure में reclaim नहीं की जा सकती
    • live entry list हर transaction पर खाली हो जाती है, लेकिन अगर एक transaction में बहुत सारा अलग-अलग data लिखा जाए, तो peak बड़ा हो जाता है

  • unique entries table को फुलाती हैं

    • dedup disk पर stored सभी blocks को track करता है, लेकिन असली लाभ केवल तब मिलता है जब refcount 1 से अधिक हो
    • refcount 1 वाली unique entry लगभग उस लागत जैसी है जो यह उम्मीद करते हुए दी जा रही है कि वही data कभी फिर लिखा जाएगा
    • dedup encryption और compression के बाद block level पर किया जाता है
    • समान original data भी तभी समान block माना जाता है जब compression method, encryption key और file के भीतर alignment तक मेल खाएँ
    • general-purpose workloads में “वास्तव में समान” blocks कम होते हैं, इसलिए dedup की लागत आसानी से लाभ से अधिक हो सकती है

Fast Dedup के सुधार

  • live entry में कमी

    • Fast Dedup सबसे पहले live entry list की memory footprint घटाता है
    • ddt_entry_t के बड़े numeric type flags को bitfield में बदलता है, और synchronization fields को सरल करता है
    • deduped data block पहली बार लिखते समय या repair write की ज़रूरत होने पर ही इस्तेमाल होने वाली 40-byte state को अलग IO state object में अलग करता है
    • पुरानी dedup entry value में चार physical entries शामिल थीं और size 256 bytes था
    • हर physical entry में तीन 128-bit DVA, refcount और birth transaction id होते हैं
    • चौथी entry पुराने dedupditto feature का अवशेष है; आधुनिक OpenZFS केवल read support करता है और नया नहीं लिखता
    • Fast Dedup में copies= बदलने पर ज़्यादा DVA की ज़रूरत हो तो मौजूदा variant को अलग entry की तरह नहीं रखता, बल्कि केवल आवश्यक additional copies allocate कर मौजूदा dedup entry में जोड़ता है
    • नई Fast Dedup table की entry value पुराने 256 bytes से घटकर 72 bytes हो जाती है
    • live list की एक entry पुराने 424 bytes से घटकर 216 bytes हो जाती है

  • dedup log की शुरुआत

    • पुराने तरीके में transaction खत्म होने पर live entry list को सीधे dedup ZAP में reflect किया जाता था, और entry के आसपास की 187 items ज़्यादातर असंबंधित होने पर भी block-level update cost आती थी
    • Fast Dedup इस observation के आधार पर dedup log जोड़ता है कि recently created/duplicated blocks के फिर duplicate या freed होने की संभावना अधिक होती है
    • transaction के अंत में live entry changes को सीधे ZAP में लिखने के बजाय log में record किया जाता है
      • crash safety के लिए on-disk log ज़रूरी है
      • तेज lookup के लिए in-memory log रखा जाता है
    • lookup order live entry list, in-memory log, dedup ZAP हो जाता है
    • on-disk log का उपयोग pool import के समय in-memory log restore करने में होता है

  • incremental log flush

    • शुरुआती तरीके की तरह अगर log बहुत बड़ा हो जाने पर एक साथ ZAP में flush किया जाए, तो सिर्फ़ कुछ हज़ार entries से भी लंबा pause हो सकता था
    • Fast Dedup हर transaction में log का कुछ हिस्सा ZAP में reflect करने वाली incremental flushing का इस्तेमाल करता है
    • flush की मात्रा वास्तविक IO में लगे समय की तुलना में adjust होती है
      • busy समय में कम लिखता है, शांत समय में ज़्यादा
      • in-memory log बड़ा होकर memory pressure बनाए तो flush तेज किया जा सकता है
    • on-disk log को append-only रखते हुए भी पूरी तरह रोके बिना खाली करने के लिए दो logs का इस्तेमाल होता है
      • एक active log है जो नए changes लेता है
      • दूसरा flushing log है जिसे ZAP में reflect किया जाता है
      • flushing log खाली हो जाए तो on-disk log को zero किया जाता है और दोनों logs की roles बदल दी जाती हैं
    • scrub या resilver जैसे pool scan में dedup log में stable position की अवधारणा नहीं होती, इसलिए scan request पर log flushing तेज कर सब कुछ dedup ZAP में reflect करने के बाद पुराने तरीके से scan किया जाता है

unique entry management और operation features

  • zpool ddtprune pool की dedup table से कुछ unique entries हटाता है
    • इसे age या percentage basis पर specify किया जा सकता है
    • age basis खासकर उन workloads के लिए उपयुक्त है जहाँ हाल में इस्तेमाल data के फिर duplicate होने की संभावना अधिक होती है
  • pruning से जिस block की dedup entry हट गई हो, अगर बाद में copy किया जाए, तो वह मौजूदा block के साथ deduplicate नहीं होगा और नए block के रूप में allocate होगा
    • हालांकि कोई पुराना unique block अचानक कई बार copy हो, तो नए block के लिए कई references बन सकते हैं
  • dedup_table_quota pool property dedup table का maximum size limit करती है
    • अगर नई entry बनाना limit पार कर दे, तो entry बनाए बिना उसे सामान्य non-dedup write के रूप में process किया जाता है
    • dedicated dedup device भर जाने पर main device में overflow न हो, इसके लिए इसे साथ में इस्तेमाल किया जा सकता है
  • zpool prefetch -t ddt dedup table को पहले से ARC में load करता है
    • pool import के तुरंत बाद performance में मदद मिल सकती है
    • Fast Dedup में भी log में न होने वाली entry lookup और flush के समय ZAP access की ज़रूरत होती है, इसलिए यह प्रभावी है
  • नए kstats और tuneables भी जोड़े गए हैं
    • 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_*
  • zpool status -D, zdb -D, zdb -S जैसे मौजूदा dedup-aware tools भी नई structure को समझने के लिए update किए गए हैं

मौजूदा dedup table के साथ compatibility

  • Fast Dedup का अधिकांश हिस्सा on-disk format change मांगता है, इसलिए यह मौजूदा dedup table पर वैसे ही लागू नहीं होता
  • मौजूदा table में भी जिन features को on-disk format change की ज़रूरत नहीं है, वे काम कर सकते हैं
    • dedup_table_quota
    • zpool prefetch -t ddt
    • ddt_stats_* lookup और hit count
    • ZAP shrink
  • dedup log को traditional table पर भी काम कराने का काम अपेक्षाकृत straightforward task के रूप में बचा है
    • हालांकि smaller live/log entry का फायदा नहीं मिलेगा
  • zpool ddtprune में मौजूदा table पर “percentage of uniques” mode जोड़ना ही आसान है
    • age mode के लिए नए entry format का data चाहिए, इसलिए मौजूदा format में यह संभव नहीं है
  • मौजूदा table को नए format में convert करने वाला feature फिलहाल नहीं है
    • जिन simple cases में copies= कभी नहीं बदला, वहाँ नया ZAP बनाकर मौजूदा entries को convert/copy करने का तरीका संभव है
    • online conversion जटिल है क्योंकि old/new ZAP को साथ-साथ lookup या write करना पड़ेगा
    • offline conversion आसान है, लेकिन pool को offline करना पड़ेगा
    • copies= change से कई variants के पास refcount हो तो full conversion असंभव हो सकता है
  • deduplicated dataset को नए dedup-सक्षम दूसरे pool में भेजने का तरीका काम करता है

“बेहतर हुआ, फिर भी क्यों ऑन न करें”

  • Fast Dedup में पुराने की तुलना में overhead कम हुआ है, इसलिए यह अधिक marginal situations में उपयोगी हो सकता है
  • लेकिन dedup अभी भी IO throughput, memory usage, dedup table size के बीच balance की समस्या है
  • general-purpose workload में duplicate हो सकने वाले blocks बहुत दुर्लभ हो सकते हैं
  • example laptop pool के zdb -S simulated DDT results में dedup benefit लगभग नहीं था
    • 11.7M entries में ज़्यादातर refcount 1 वाली unique entries थीं
    • वास्तव में dedup हो सकने वाली entries की संख्या कुल में rounding error के स्तर की थी
    • यह dedup = 1.00 के रूप में दिखा
  • ऐसे cases में dedup ऑन करने से लगभग कुछ हासिल नहीं होता, सिर्फ़ IO और memory pressure बढ़ता है

BRT/block cloning कब बेहतर है

  • OpenZFS 2.2 से BRT, यानी block cloning या reflinks, उपलब्ध हैं
  • dedup table एक ऐसी structure है जो बिना context के यह पता करती है कि “क्या यह data पहले से disk पर है”
  • आधुनिक systems में copy operation को copy होने की बात storage stack तक पहुँचाने के cases होते हैं
    • Linux और FreeBSD filesystems का copy_file_range()
    • macOS का copyfile()
    • Windows का FSCTL_SRV_COPYCHUNK
    • NFS, CIFS, OS block device driver, SCSI EXTENDED COPY, NVMe Copy आदि में भी समान features हैं
  • अगर client program और intermediate layers copy offload signal pass करें, तो OpenZFS BRT में केवल refcount बढ़ा सकता है
  • BRT में अगर block clone नहीं हुआ तो कोई cost नहीं लगती, और clone होने पर entry 16 bytes की होती है
  • example pool में BRT ने used 292M; saved 309M; ratio 2.05x दिखाया
  • dedup simulation की तुलना में raw saving थोड़ी कम और समान स्तर की है, लेकिन clone न हुए सभी blocks को track करने की बड़ी लागत नहीं है

practical decision criteria

  • Fast Dedup traditional dedup के तीनों axes—IO throughput, memory usage, dedup table size—को बेहतर करता है
  • failure की स्थिति में catastrophic cost भी कम हुई है, और operators को table limit/clean करने के tools भी मिले हैं
  • फिर भी लाभ पाने के लिए conditions स्पष्ट हैं
    • data scale बहुत बड़ा होना चाहिए
    • वही data बहुत बार copy होना चाहिए
    • block cloning या snapshot clone जैसे OpenZFS के अन्य zero-copy options इस्तेमाल नहीं कर सकने चाहिए
  • अगर workload में client “copy कर दो” का स्पष्ट signal दे सकता है, तो block cloning कम लागत में बड़ा लाभ दे सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-10-31
Hacker News की राय

  • अगर ऑफ़लाइन deduplication हो, या deferred deduplication हो जो पूरे pool को नीचे लाए बिना काम करे, भले ही तुरंत न चले, तो अच्छा होगा
    deduplication चालू करने पर हर write और free operation पर deduplication table lookup और write की ज़रूरत पड़ना ज़्यादातर मामलों में गलत तरीका लगता है। डेटा लिखते समय आप चाहते हैं कि काम जितना जल्दी हो सके पूरा हो, भले ही disk space थोड़ा ज़्यादा लगे; इसी वजह से आप काम कर रही फ़ाइलों को 7zip archive के अंदर स्टोर नहीं करते। बाद में जब system खाली हो, तब ZFS duplicate डेटा ढूँढकर BRT जैसी किसी चीज़ से space वापस ले ले, तो अच्छा होगा; और यह सामान्य scrub operation के हिस्से के रूप में भी किया जा सकता है

    • deferred/ऑफ़लाइन deduplication के लिए Block Pointer Rewrite चाहिए, लेकिन ZFS असली CAS system नहीं है, इसलिए आगे भी सही BP rewrite मिलना मुश्किल है
      physical location Merkle hash tree में hash होकर जाती है, इसलिए physical location बदलने के लिए उस node तक जाने वाले सभी internal nodes को फिर से लिखना पड़ता है, और इसकी लागत बहुत ज़्यादा है। बेहतर design यह होता कि block pointer वाले सभी nodes को दो हिस्सों में बाँटा जाता: एक हिस्सा जिसमें सिर्फ logical block pointer हो और वही tree में hash हो, और दूसरा हिस्सा जिसमें उस logical pointer की physical location को cache की तरह रखा जाए लेकिन Merkle tree में hash न किया जाए। तब BP rewrite के लिए सिर्फ वही blocks फिर से लिखने पड़ते जो Merkle tree का हिस्सा नहीं हैं। मौजूदा structure में ZFS से मनचाही सुविधा पाना मुश्किल है, लेकिन अगर read के समय hash mismatch आए तो pointer के hash से deduplication table में block खोजकर deduplicated block को फिर allocate करने जैसी कोई workaround शायद संभव हो। इसकी कीमत शायद एक बेकार read जितनी होगी, इसलिए बहुत बुरी नहीं, लेकिन जब BP rewrite संभव नहीं होता तो आम तौर पर ऐसे ही जोड़-तोड़ वाले उपाय आते हैं
    • यह तरीका Windows deduplication की पद्धति जैसा है। मैंने इसे काफ़ी इस्तेमाल किया है, और अगर hardware पर्याप्त हो तो अनुभव आम तौर पर संतोषजनक रहा
      यह RAM और I/O बहुत खाता है, लेकिन “groveler” को schedule और limit किया जा सकता है। हाँ, Windows 2012 R2 के ज़माने में एक bug के कारण data-eating corruption झेलनी पड़ी थी
    • यह ऑफ़लाइन duplicate file detector से भी संभव है
      जैसे jdupes या duperemove। ज़रूरी system calls के support के लिए मैंने ZFS और duperemove, दोनों तरफ PR भेजे थे। ZFS वाली तरफ review में बहुत समय लग गया, और मुझे एहसास हुआ कि मैं इसे पूरा करना लगभग भूल ही गया था, इसलिए फिर से देखना होगा
    • ZFS में मौजूदा snapshots को बदलने की क्षमता, भले ही डेटा पूरी तरह सुरक्षित रहे, बहुत सीमित है। इसलिए ऐसी सुविधा अच्छी होती, लेकिन अगर आप Block Pointer Rewrite का इंतज़ार कर रहे होते, तो शायद बहुत पहले ही मर चुके होते
    • inline deduplication की अच्छी बात यह है कि अगर block hash पहले से मौजूद हो, तो उस block को वास्तव में लिखने की ज़रूरत नहीं पड़ती
      कई स्थितियों में यह write I/O को बहुत कम कर सकता है। deduplicating storage array में दो VM के बीच file copy करने पर असली डेटा कॉपी नहीं किया जाता, सिर्फ original block का reference count बढ़ाया जाता है। operating system की नज़र में यह बेहिसाब TB/s write speed जैसा दिखता है, जो काफ़ी शानदार है

  • यह दावा कि “पारंपरिक deduplication की मूल समस्या यह है कि इसका overhead इतना बड़ा है कि दुर्लभ और बहुत विशिष्ट workload के अलावा इसकी भरपाई मुश्किल है” काफ़ी अजीब लगता है
    मैंने Pure और Dell/EMC arrays के साथ काम किया है, और VMWare workloads में आम तौर पर deduplication/compression से कम-से-कम 3:1 की बचत मिली। base VM image की सिर्फ एक copy रखना बहुत अच्छा काम करता है। syslog server में भी deduplication/compression अच्छा चला और 6:1 की बचत देखी। deduplication का असर काफी हद तक hashed block size पर निर्भर करता है, और block जितना छोटा हो, उतना अच्छा। block छोटा होने पर matching blocks मिलने की संभावना तेज़ी से बढ़ती है, और अनुभव के आधार पर पसंदीदा block size 4KB है

    • VM images बहुत ज़्यादा दोहराव वाली जानकारी होती हैं, जैसे Windows Server images की C drive लगभग एक जैसी होती है, जबकि मूल लेख ने उदाहरण के तौर पर अपने laptop की सामग्री ली थी
      और ऐसा भी लगता है कि वह compression और deduplication, यानी दो अलग चीज़ों को मिला रहा है। ZFS में pool पर compression चालू की जा सकती है और यह लगभग हमेशा फ़ायदेमंद है, जबकि deduplication को बंद रखा जा सकता है
    • base VM images दुर्लभ और विशिष्ट workload की श्रेणी में आती हैं, और deduplication के समझदारी वाले कुछ गिने-चुने मामलों में से एक हैं
      लेकिन अगर आप ZFS filesystem पर VM host कर रहे हैं, तो संभव है कि आप block या filesystem clone जैसी बेहतर strategy इस्तेमाल कर रहे हों। ऐसा न करना उस environment में ZFS की एक मुख्य खासियत को छोड़ देने जैसा है। सामान्य file server या व्यक्तिगत desktop/laptop उपयोग में आम तौर पर duplicate blocks बहुत कम होते हैं, इसलिए overhead बेकार जाता है। backup में यह इस बात पर निर्भर कर सकता है कि implementation कैसी है और encryption filesystem layer से पहले होती है या नहीं। compression बिल्कुल अलग बात है, और ZFS की मौजूदा best practice लगभग सभी workloads में इसे default रूप से चालू रखने की है। आजकल CPU cost इतनी कम है कि उसका ज़िक्र करना भी मुश्किल से ज़रूरी है, और storage savings से अलग I/O savings भी काफ़ी हो सकती है। सामान्य log storage में अनुभव के अनुसार 6:1 से कहीं बेहतर बचत भी संभव है
    • मैंने खुद नहीं किया, लेकिन पुराने ZFS deduplication के बारे में अक्सर उद्धृत आँकड़ा यह है कि हर 1TB disk पर 5GB RAM चाहिए
      अगर मान लें कि आज 1TB disk लगभग 15 डॉलर की है और server RAM के 5GB लगभग 25 डॉलर के, तो सिर्फ break-even तक पहुँचने के लिए भी 3:1 deduplication ratio चाहिए। डेटा अच्छी तरह मेल खाए तो शायद 1GB प्रति TB में भी काम चल जाए, लेकिन अगर किस्मत खराब हो तो 5GB भी काफ़ी नहीं हो सकता। इसलिए लेख में कहा गया कि ZFS deduplication का एक छोटा-सा sweet spot है जहाँ डेटा बिल्कुल फिट बैठना चाहिए, और यही वजह है कि ज़्यादातर लोग इसकी परवाह नहीं करते। दूसरे filesystems आम तौर पर आर्थिक रूप से बेहतर offline deduplication को पसंद करते हैं
    • VM में deduplication के फ़ायदे जाने-पहचाने हैं, इसलिए वहाँ इसका असर दिख सकता है। लेकिन ZFS सिर्फ enterprise SAN नहीं बल्कि general-purpose filesystem भी है, इसलिए ZFS के बहुत-से उपयोगकर्ता VM नहीं चला रहे होते
      syslog में deduplication/compression के अच्छे चलने की बात को अगर विस्तार से देखें, तो deduplication और compression एक ही चीज़ नहीं हैं। enterprise storage दुनिया में इन्हें अक्सर साथ बाँधा जाता है, लेकिन logs में शायद फ़ायदा deduplication से नहीं बल्कि compression से आ रहा है, और ZFS में compression तो पहले से मौजूद है
    • base VM images की कई deep copies न रखना निश्चित ही समझदारी है, लेकिन ZFS में deduplication सही तरीका नहीं है
      इसके बजाय base image को clone करने पर बदलाव होने तक लगभग कोई space नहीं लगता। यह ZFS की copy-on-write प्रकृति की वजह से संभव है। ZFS deduplication का मतलब volume में लिखे जा रहे डेटा की पहले से मौजूद copies ढूँढना है। container image storage जैसी कुछ स्थितियों में यह काफ़ी उचित हो सकता है, लेकिन अगर आपको पहले से पता है कि कोई dataset शुरू से ही किसी दूसरे का clone है, तो यह बहुत अक्षम तरीका है

  • पहले ZFS deduplication का काफ़ी व्यापक इस्तेमाल किया था और बड़ा फ़ायदा मिला था। खास उपयोग VMWare cluster के लिए storage था, और ज़्यादातर सामग्री एक जैसी होने वाली सैकड़ों Linux और Windows VM थीं। यह Docker से पहले के समय की बात है

    • यहाँ VM पर deduplication इस्तेमाल करने के कई उदाहरण दिख रहे हैं, लेकिन लगता है कि इसे filesystem की बजाय hypervisor में implement करना कहीं ज़्यादा efficient नहीं होगा?
    • सहमत। हाल ही में Ubuntu के “experimental” zfs के साथ आया नया work laptop मिला, और nix store पर deduplication इस्तेमाल करना सच में बहुत मददगार रहा

  • fast deduplication को लेकर बहुत उत्साह है। कई सालों से ArchiveBox डेटा पर ZFS deduplication इस्तेमाल करना चाहता था, और fast deduplication की वजह से शायद अब एक ही collection में लाखों URL archive करना और filesystem से पूरी compression संभालवाना आखिरकार संभव हो जाएगा
    archive डेटा में jquery.min.js, bootstrap.min.css, logo images जैसी चीज़ें हज़ारों snapshots में बार-बार आती हैं। दूसरे tools एक crawl के भीतर compress करके wacz या warc.gz files बनाते हैं, लेकिन अभी तक ऐसा नहीं लगता कि किसी tool ने अब तक लिए गए सभी snapshots के पूरे database में cross-cutting compression करने की कोशिश की हो। यह भी जानना चाहता हूँ कि क्या किसी ने probabilistic deduplication जैसा कोई approach आज़माया है, ताकि पूरी deduplication hash table को जस का तस store न करना पड़े। जैसे लगभग 100 block hashes को buckets में group करना, और Bloom filter में उनका ultra-compressed representation store करना। write के समय लिखे जाने वाले block के hash को Bloom filter में lookup करना, और अगर संभावित deduplication hit मिले तो उस bucket के 100 blocks को सीधे scan करके वही hash ढूँढना। सैद्धांतिक रूप से अलग-अलग resolution वाले Bloom filters की hierarchy भी हो सकती है, और memory pressure ज़्यादा होने पर high-resolution filter को dynamically disk पर उतारा जा सकता है। अगर Bloom filter accuracy को tunable parameter बनाया जाए, तो CPU time/overhead बनाम बचाए गए bytes के अनुपात के बीच अपनी पसंद चुनी जा सकती है

    • इस बदलाव के बाद भी ZFS deduplication अब भी block alignment आधारित रहेगा, इसलिए अगर दोहराई जाने वाली web assets WARC archive के भीतर हमेशा एक ही offset पर नहीं हैं, तो यह शायद अच्छा match नहीं होगा
      dm-vdo भी ऐसे ही काम करता है। इसकी जगह लंबी range देखने वाली solid compression, या WARC files को directory-जैसी structure में unpack करना, या content-defined chunking आधारित कोई FUSE system बेहतर हो सकता है। शायद Seafile ऐसा करता हो
    • use case समझ में आता है, लेकिन ज़्यादातर मामलों में, खासकर इस मामले में, इसे client side पर implement करना कहीं बेहतर लगेगा
      WARC standard देखें तो उसमें पहले से hash-based deduplication और पहली बार store करने के बाद pointer इस्तेमाल करने का तरीका मौजूद है। इसलिए यह filesystem layer deduplication के कम उपयुक्त होने का बिल्कुल सटीक उदाहरण है
    • use case थोड़ा अलग है, लेकिन अगर zbackup के बारे में नहीं जानते, तो शायद आपको पसंद आए

  • समझ नहीं आता कि RAM usage कम रखते हुए इसे सही तरह से चलाना इतना मुश्किल क्यों हो रहा है। commercial storage appliances तो जुड़े हुए disk capacity की तुलना में “कम” RAM वाले systems पर भी कम-से-कम लगभग 10 साल पहले से यह कर रहे थे
    बस fingerprints को database में store करके रात में scan करते हुए block pointers ठीक नहीं किए जा सकते क्या?

    • “block pointers को ठीक करना” ही इसकी वजह है। कई कारणों से ZFS में block pointer rewrite की क्षमता नहीं है
      यह लंबे समय से माँगी गई सुविधा है, और अगर यह संभव हो जाए तो defragmentation भी की जा सकती है। मैंने सोचा था कि virtual memory की तरह block pointer indirection इस्तेमाल करके इसे थोड़ी speed cost पर हल किया जा सकता है, लेकिन मैं ZFS developer नहीं हूँ, इसलिए यक़ीनन कुछ छूट रहा होगा। http://eworldproblems.mbaynton.com/posts/2014/zfs-block-poin... / https://github.com/openzfs/zfs/issues/3582
    • block pointers को ठीक करना वही एक चीज़ है जो ZFS कभी करना ही नहीं चाहता था
    • DragonFlyBSD और Hammer2 इस्तेमाल करने का भी विकल्प है। Hammer2 online और offline deduplication दोनों को support करता है और कई मायनों में ZFS से बहुत मिलता-जुलता है
      बड़ी कमी यह है कि इसमें RDMA इस्तेमाल करने वाला file transfer protocol नहीं है। सुना है कि Hammer2 को FreeBSD पर चलाने के लिए एक experimental branch भी है। लेकिन FreeBSD में भी RDMA support नहीं है। FreeBSD 15 में Chelsio ने NVMe-oF target और initiator support को sponsor किया है, लेकिन लगता है वह सिर्फ TCP के लिए है

  • cp --reflink=auto इस्तेमाल करें
    इससे file-level deduplication मिल सकती है। यह command lightweight copy करती है, और file-level ZFS clone की तरह data blocks केवल modify होने पर ही copy होते हैं। यह hard link नहीं बल्कि copy है। reflink support करने वाले दूसरे copy-on-write transactional filesystems पर भी यही तरीका काम करेगा

  • मैं सच में ZFS इस्तेमाल करना चाहता था, लेकिन सारा data स्वाभाविक रूप से encrypted होना चाहिए। मगर इसका इस्तेमाल उम्मीद से कहीं ज़्यादा जटिल हो जाता है, और चीज़ें उलझने लगती हैं, इसलिए यह देखकर हैरानी हुई कि बहुत से लोग बस अपने data को encrypt ही नहीं करते
    Proxmox के website पर “Enterprise” लिखा है, इसलिए लगा था कि default install में encryption support होगा, लेकिन encryption के साथ इस्तेमाल करने पर कुछ महत्वपूर्ण features खो जाते हैं। issue tracker भी ज़रूर देखना चाहिए। operating filesystem में कुछ ऐसी चौंकाने वाली चीज़ें हैं जिनकी मैंने उम्मीद नहीं की थी

    • ZFS को encrypt करने का सबसे अच्छा तरीका encrypted volume, जैसे LUKS volume, के ऊपर unencrypted ZFS चलाना है। ZFS “encryption” plain text में बहुत कुछ छोड़ देती है, इसलिए असहज लगता है

  • काश filesystem के लिए कोई बिल्कुल अलग API होती। compatibility बनाए रखने के कारण हर operating system की filesystem API surface पूरी तरह से उलझी हुई है

    • अंदरूनी रूप से ZFS मूलतः एक object store है। इसे object store API के रूप में expose करने की कोशिश हुई थी, लेकिन दुर्भाग्य से लगता है कि वह कहीं आगे नहीं बढ़ी
      presentation ढूँढने की कोशिश की, लेकिन नहीं मिली। लगा था Developer Summit में देखा था, शायद नहीं
    • यह इतना उलझा हुआ क्यों है, और इसकी जगह क्या हो सकता है? क्या AWS S3-शैली API कोई सुधार होगी?

  • deduplication को भूलकर ZFS compression इस्तेमाल करना कहीं बेहतर cost-benefit देता है

    • अगर dataset पहले से बहुत compress किए हुए media files का हो, तो वह अपवाद है
      आम तौर पर rsync jobs में बड़े video files के लिए मैं compression बंद कर देता हूँ। compression storage या transfer में कम या शून्य फायदा देती है, लेकिन RAM और CPU खाती है। deduplication Virtual Machine OS images के लिए अच्छी है, क्योंकि storage cost का बड़ा हिस्सा दोहराए गए base images से आता है

  • सामान्य-purpose deduplication सैद्धांतिक रूप से अच्छा लगता है, लेकिन व्यवहार में कई बार ठीक से काम नहीं करता। IPFS, rsync की तरह डेटा को deduplicate करने के लिए variable-size chunks और rolling hash का उपयोग करता है, लेकिन वास्तविकता में इससे कोई फर्क नहीं पड़ता और बेवजह complexity ही बढ़ती है