ZFS 2.3 जारी, RAIDZ Expansion फीचर शामिल

 (github.com/openzfs)
1 पॉइंट द्वारा GN⁺ 2025-01-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • OpenZFS 2.3.0 में मुख्य फीचर के रूप में RAIDZ Expansion शामिल है, जो मौजूदा RAIDZ pool में नए devices जोड़कर downtime के बिना capacity बढ़ाने की सुविधा देता है
  • Fast Dedup मौजूदा deduplication फीचर के performance को काफी बेहतर बनाता है, और इसके साथ codebase भर में performance improvements भी शामिल हैं
  • Direct IO पढ़ने/लिखने के दौरान ARC को bypass करने देता है, जिससे यह NVMe devices जैसे उन environments के लिए उपयोगी है जहाँ caching efficiency को कम कर सकती है
  • अक्सर इस्तेमाल होने वाले commands के लिए वैकल्पिक JSON output, अधिकतम 1023 अक्षरों के file·directory name support, और पिछले versions की समस्याओं को संबोधित करने वाले महत्वपूर्ण bug fixes जोड़े गए हैं
  • support range Linux kernel 4.18~6.12 और FreeBSD 13.3, 14.0~14.2 तक है, और इस release cycle में 134 लोगों ने योगदान दिया है

OpenZFS 2.3.0 में क्या बदला

  • OpenZFS 2.3.0 का अपडेट storage expansion, deduplication performance, I/O path, command output format, और filename length support पर केंद्रित है
  • release tag zfs-2.3.0 है, और इसमें OpenZFS 2.2.0 के बाद के बदलाव शामिल हैं

स्टोरेज विस्तार और performance improvements

  • RAIDZ Expansion मौजूदा RAIDZ pool में नए devices जोड़कर downtime के बिना storage capacity बढ़ाने देता है
  • Fast Dedup मौजूदा OpenZFS deduplication फीचर का एक बड़ा performance upgrade है
  • Direct IO read/write के दौरान ARC bypass की अनुमति देता है
    • इसका लक्ष्य उन स्थितियों में performance सुधारना है जहाँ NVMe devices की तरह caching efficiency में बाधा बन सकती है
  • codebase भर में कई performance improvements भी शामिल हैं

command output और name length

  • JSON सबसे अधिक उपयोग होने वाले commands में वैकल्पिक JSON output जोड़ता है
  • Long names file और directory names को अधिकतम 1023 अक्षरों तक support करता है

स्थिरता, platform, योगदान

  • पिछले versions में रिपोर्ट की गई समस्याओं को संबोधित करने वाले महत्वपूर्ण bug fixes शामिल हैं
  • supported platforms:
    • Linux kernel 4.18~6.12
    • FreeBSD 13.3, 14.0~14.2
  • इस release cycle में 134 contributors ने भाग लिया

documentation और change log

module option changes

  • सभी options और उनके नियंत्रण targets module parameters दस्तावेज़ में संकलित हैं
  • नए module options में RAIDZ expansion, deduplication log, Direct IO, allocator, scrub, resilver से जुड़े items शामिल हैं
    • उदाहरण: raidz_expand_max_copy_bytes, raidz_expand_max_reflow_bytes, zfs_dio_enabled, zfs_dedup_log_mem_max, zfs_scrub_after_expand
  • हटाए गए module option:
    • zfetch_array_rd_sz
  • बदले गए module options:
    • zfs_arc_shrinker_limit
    • zfs_bclone_enabled
    • zfs_vdev_disk_classic
    • zio_taskq_write

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

1 टिप्पणियां

 
GN⁺ 2025-01-15
Hacker News की राय

  • कई सालों से तैयार हो रहा ZFS RAIDZ विस्तार आखिरकार शामिल हो गया
    मुख्य फीचर्स हैं: मौजूदा RAIDZ पूल में डिवाइस जोड़कर बिना रुकावट क्षमता बढ़ाने वाला RAIDZ विस्तार, OpenZFS deduplication की performance को काफी बढ़ाने वाला fast deduplication, ARC को bypass करके NVMe जैसे environments में जहां cache कम प्रभावी हो सकता है performance सुधारने वाला direct I/O, अक्सर इस्तेमाल होने वाले commands के लिए optional JSON output, और file/directory names में अधिकतम 1023 characters का support

    • और सटीक कहें तो इसका मतलब है कि मौजूदा RAIDZ vdev में नया device, यानी disk, जोड़ा जा सकता है
    • अगर Proxmox को ZFS और NVMe पर चला रहे हैं, तो 2.3 rollout होने पर direct I/O enable करना बेहतर होगा या नहीं, यह जानने की उत्सुकता है
      जानना चाहता/चाहती हूं कि यह feature किस use case के लिए है
    • शुरुआती 4 चीजें वाकई बड़े बदलाव लगती हैं
    • फिर भी लगता है कि vdev removal अभी भी संभव नहीं है
    • उत्सुकता है कि इस feature को encryption के साथ कितनी अच्छी तरह test किया गया है
      यह भी सवाल है कि ZFS team encryption को सच में first-class priority मानती है या नहीं
      Linux पर ZFS ने Solaris के ZFS की प्रतिष्ठा काफी हद तक विरासत में पाई है, लेकिन production में इसे इस्तेमाल करने वालों को वास्तविकता देखने के लिए issue tracker को काफी ध्यान से देखना चाहिए

  • यह समझ नहीं आता कि user count के हिसाब से सबसे बड़े PC platform Windows पर अभी भी ZFS का कोई जवाब क्यों नहीं है
    Microsoft के पास WinFS था और फिर ReFS भी आया, लेकिन वे पीछे चले गए हैं; development जारी है और Win11 में कभी-कभी कुछ हिस्से आते भी हैं, मगर official release दिखता नहीं
    कुछ individuals ZFS compatibility layer बनाने का बड़ा काम करने की कोशिश कर रहे हैं, लेकिन यह अभी mature या practical-use level से काफी दूर है
    समझ नहीं आता कि Windows अब भी 32 साल पुराना file system कैसे इस्तेमाल कर रहा है

    • सच कहूं तो Linux की स्थिति भी बहुत बेहतर नहीं है
      ZFS के साथ Linux में licensing issue है, जिससे full integration रुक जाता है, और Btrfs 15 साल से development में होने के बावजूद features और stability में अभी भी ZFS तक नहीं पहुंचता
      ज्यादातर Linux distributions अभी भी default के रूप में 19 साल पुराना ext4 इस्तेमाल करते हैं, और ext4 भी असल में लगभग NTFS जितनी ही उम्र वाले ext2 के ऊपर extensions चढ़ाने जैसा है
      निष्पक्ष रूप से देखें तो file system जितने महत्वपूर्ण OS components कम ही होते हैं, और production में 10 साल से ज्यादा proven न हुए file system को छूना भी बहुत लोग नहीं चाहते
    • वजह सरल है। file system को जो अधिकांश बोझ उठाना होता, उसे उस file system के नीचे रखा हुआ enterprise storage hardware उठा लेता है
      snapshots, block-level deduplication, object storage technology, RAID/resilience, resizing जैसे जरूरी features storage equipment संभालता है
      आधुनिक storage appliances लगभग black magic के स्तर के होते हैं, इसलिए NTFS में और features होना जरूरी नहीं
      NAS/SAN के जरिए transparently access कर लें, या सक्षम disk box के ऊपर NTFS volume store कर लें
      Linux दुनिया के advanced क्षेत्र में Lustre और GPFS हैं, और ZFS आम तौर पर उन use cases के लिए सही है जहां performance core focus नहीं, लेकिन resilience जरूरी है
    • mainline Linux kernel में भी ZFS के बराबर कोई जवाब नहीं है
      मेरा मानना है कि यह मुश्किल और high-risk है, जबकि reward अक्सर सिर्फ technical respect तक सीमित रहता है
    • Windows और Linux इस्तेमाल करने वाले, लेकिन ZFS न इस्तेमाल करने वाले end user के तौर पर, मैं जानना चाहता/चाहती हूं कि मैं क्या miss कर रहा/रही हूं
    • Windows के लिए OpenZFS release candidate stage (rc11) तक पहुंच गया है, और volume mount के आसपास कुछ bugs बचे हैं
      ये गंभीर नहीं हैं, लेकिन फिलहाल encryption से बचना बेहतर है; बचे हुए issues ठीक करने के लिए हर कुछ हफ्तों में नया release candidate आने जितनी तेजी से development चल रही है
      इसमें Storage Spaces मिलाकर अलग-अलग type या size की disks को pool किया जाए, और location, redundancy, tiering को हर Space के हिसाब से define किया जाए, तो Windows अब advanced storage platform बन जाता है
      Windows Server, जैसे सस्ता 2022/2025 Essentials, इस्तेमाल करें तो LAN और virtual hard disk .vhdx पर 10Gbyte/s तक performance वाला SMB Direct/RDMA भी इस्तेमाल कर सकते हैं, जो iSCSI की तुलना में बिना setup वाला और तेज alternative बनता है
      इसलिए ZFS web GUI napp-it cs को Solaris से Windows पर port किया गया, ताकि Storage Spaces और ZFS, साथ ही Proxmox जैसे remote OpenZFS servers manage किए जा सकें; non-commercial use के लिए यह free है

  • यह अच्छा लगा कि विस्तार सुविधा को काफ़ी conservative तरीके से बनाया गया है
    विस्तार पूरी तरह transparent और resume करने योग्य ही नहीं है, बल्कि पूरी प्रक्रिया के दौरान redundancy भी बनाए रखता है
    हालांकि एक छोटी-सी बात है जो लोगों को पता होनी चाहिए
    विस्तार पूरा होने के बाद भी मौजूदा blocks पुराने data-to-parity ratio को बनाए रखते हैं। उदाहरण के लिए 5-wide RAIDZ2, 3 data और 2 parity के रूप में बड़े disk set में फैल जाता है
    नए blocks नए data-to-parity ratio के साथ लिखे जाते हैं। उदाहरण के लिए 5-wide RAIDZ2 को एक बार expand करके 6-wide बनाने पर 4 data और 2 parity हो जाता है

    • मुझे पक्का नहीं कि वह सच में कोई caveat है। इसका मतलब बस इतना है कि मौजूदा data कम-से-कम optimal placement में रह सकता है
      फिर भी RAIDZ N के फायदे बने रहते हैं, यानी अधिकतम N disks पूरी तरह fail हो जाएँ तब भी pool चलता रहता है
    • वह caveat काफ़ी expected behavior है। ZFS features को आम तौर पर मौजूदा blocks को दोबारा नहीं लिखते मानकर चलना चाहिए
      उदाहरण के लिए configuration changes भी सिर्फ नए data पर लागू होते हैं
    • सच कहूँ तो यह काफ़ी बड़ा caveat है
      Da1 Db1 Dc1 Pa1 Pb1
      Da2 Db2 Dc2 Pa2 Pb2
      Da3 Db3 Dc3 Pa3 Pb3
      ___ ___ ___ Pa4 Pb4
      यहाँ ___ खाली space है। एक disk जोड़कर expand करने पर logically हम कुछ ऐसा expect कर सकते हैं
      Da1 Db1 Dc1 Da2 Pa1 Pb1
      Db2 Dc2 Da3 Db3 Pa2 Pb2
      Dc3 ___ ___ ___ Pa3 Pb3
      ___ ___ ___ ___ Pa4 Pb4
      लेकिन मेरी समझ के मुताबिक असल में expansion कुछ इस तरह होता है
      Da1 Db1 Dc1 Dd1 Pa1 Pb1
      Da2 Db2 Dc2 Dd2 Pa2 Pb2
      Da3 Db3 Dc3 Dd3 Pa3 Pb3
      ___ ___ ___ ___ Pa4 Pb4
      यहाँ Dd1~3 blocks बस waste हो जाते हैं। यानी array में नई disk जोड़ने पर भी खाली storage सिर्फ 25% ही बढ़ता है
      उदाहरण के लिए 8TB disks के साथ पहले कुल 24TB usable space था और expansion से पहले 4TB खाली था, तो expansion के बाद खाली space 5TB हो जाएगा
      काश कोई बताए कि मैं गलत समझ रहा हूँ। अगर गलतफहमी नहीं है, तो implementation काफ़ी बेकार लगती है

  • ZFS users के लिए यह बड़ी खबर है। शायद hobby और home users के लिए खास तौर पर, लेकिन फिर भी बड़ी है
    RAIDZ expansion कई सालों से सबसे ज्यादा मांगे गए features में से एक था

    • मैं अभी ZFS से बहुत परिचित नहीं हूँ और release notes में भी नहीं मिला, तो सोच रहा हूँ कि expansion सिर्फ समान size की disks पर ही काम करता है क्या
      जानना चाहता हूँ कि बड़ी या छोटी disk जोड़ी जा सकती है या सभी disk sizes समान होने चाहिए

  • यह online expansion है। Expansion खुद पहले भी संभव था, लेकिन array को down करना पड़ता था
    बड़े drives पर move करना भी संभव था, लेकिन एक-एक करके replace करना पड़ता था, और स्वाभाविक रूप से नई capacity सभी drives upgrade करने के बाद ही मिलती थी
    जहाँ तक मुझे पता है, pool shrinking अभी भी संभव नहीं है। इसलिए अगर 5-drive pool में 6th drive जोड़ते हैं, तो data बहुत कम होने पर भी वापस 5 पर नहीं लौट सकते

  • आखिरकार!
    अभी खरीदे जा सकने वाले सबसे महंगे और high-density hard disks में से 4 के साथ RAID-Z3 जैसी borderline crazy single vdev configuration भी संभव हो गई
    शुरुआत में 3 disks की redundancy होने से effective space utilization सिर्फ 25% है, लेकिन जैसे-जैसे space की जरूरत बढ़े, एक-एक disk खरीदकर करीब 12 disks तक expand कर सकते हैं
    समय के साथ disk prices घटेंगी, और disks अलग-अलग समय पर जोड़ने से failure probability भी spread हो जाएगी

    • सही है, लेकिन sibling comment भी देखना चाहिए
      array expand करने पर मौजूदा data ज्यादा efficiently store नहीं होता
      नया parity/data ratio पाने के लिए data को जबरन copy करके पुराने inefficient version को हटाना होगा। उदाहरण के लिए ऐसे tool की जरूरत होगी [1]
      निजी तौर पर मुझे लगता है कि अलग-अलग complete RAID-Z configurations खरीदकर नई configuration जोड़ना, या पुरानी configuration को disk-by-disk replace करते जाना कहीं बेहतर है
      [1] https://github.com/markusressel/zfs-inplace-rebalancing

  • यह जानना है कि ZFS की तुलना btrfs से कैसी है
    अभी होम सर्वर पर btrfs इस्तेमाल कर रहा/रही हूँ, लेकिन कुछ अजीब समस्याएँ कई बार झेल चुका/चुकी हूँ
    ZFS पर जाने के बारे में सोच रहा/रही हूँ, लेकिन उसी तरह की स्थिति में नहीं फँसना चाहता/चाहती

    • करीब 15 साल पहले Linux 2.6.33-rc4 के आसपास पहली बार btrfs आज़माया था
      3 दिन में एक ऐसी फ़ाइल बन गई जिसे हटाया नहीं जा सकता था, इसलिए उसका इस्तेमाल बंद कर दिया और बाद में ZFS मिला
      ZFS में भी कुछ कम गंभीर समस्याएँ थीं, लेकिन उस समय मैं कंप्यूटर साइंस का छात्र था/थी और btrfs में देखी समस्याओं की तुलना में वे मामूली लगीं, इसलिए लगा कि उन्हें ठीक किया जा सकता है
      अगले 18 महीनों में परेशान करने वाली सारी समस्याएँ ठीक कीं और उस समय के ZFSOnLinux repository में patches भेजे, और उस प्रयास ने Linux पर ZFS को production environment में इस्तेमाल लायक बनाने में मदद की
      उसके बाद से लगातार ZFS इस्तेमाल किया है और यह अच्छी तरह काम करता आया है
      अगर btrfs की हालत बेहतर होती तो मैं btrfs contributor बन गया/गई होता/होती। लेकिन उस समय इसकी हालत खराब ही नहीं थी, बाद में भी जब-जब गंभीर उपयोग के लिए इसे आज़माया, जगह बाकी होने के बावजूद अक्सर ENOSPC आने जैसी समस्याएँ लगातार अड़चन बनती रहीं
      दूसरी ओर ZFS बस काम करता है। मैंने और कई लोगों ने इसे अच्छी तरह काम कराने के लिए काफी काम किया है
      सबसे बड़ा फर्क यह है कि ZFS की बुनियाद बेहद मजबूत थी, और इसकी वजह शानदार regression testing व्यवस्था है
      user-space version code को randomly चलाकर production environment में फटने से पहले bugs ढूँढ लेता है, और हर प्रस्तावित बदलाव पर tests का समूह चलाकर bugs पकड़ता है
      ZFS में प्रस्तावित बदलावों की review करने वाले लोग भी दूसरे file systems से ज्यादा हैं। Btrfs developers भी अक्सर कहते हैं कि दोनों file systems के बीच manpower का बड़ा फर्क है, और मुझे याद है कि उन्होंने लगभग 6 गुना अंतर बताया था
      खैर, ZFS इस्तेमाल करके पछताने वाले लोग कम ही हैं, इसलिए शायद आपको यह पसंद आएगा
    • ZFS करीब 20 साल से production environment में इस्तेमाल हो रहा है
      BTRFS documentation के मुताबिक BTRFS अभी पूरी तरह production environment के लिए उपयुक्त नहीं है: https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid5...
      कुछ सरल use cases में BTRFS को production environment के लिए पर्याप्त माना जा सकता है, लेकिन नतीजे environment के हिसाब से बदलते हैं
    • btrfs के लक्ष्य ZFS जैसे हैं, लेकिन यह कहीं कम mature है
      DKMS की जरूरत नहीं थी, इसलिए इसे root partition पर इस्तेमाल किया, लेकिन समस्याएँ बहुत थीं
      काफी साधारण तरीके से सिर्फ mirror के रूप में इस्तेमाल किया था, लेकिन एक दिन array की एक drive में समस्या आने पर btrfs ठीक से टिक नहीं पाया
      याद है कि उसने सब कुछ read-only में फिर से mount कर दिया था, और default रूप से degraded mode में काम नहीं किया
      checksum जैसी सुविधाओं के बिना mdraid भी इससे बेहतर होता
      ZFS भी इसी तरह array को faulted के रूप में mark करता है, लेकिन स्वाभाविक रूप से इस्तेमाल जारी रखने देता है
      इसका default व्यवहार RAID जैसा नहीं था—यानी data को फिर से पढ़कर वापस लाने वाला R हिस्सा असल में गायब था—इस वजह से भरोसा उठ गया
      ZFS पर जाने के बाद से कोई समस्या नहीं हुई, और community व अच्छे tools भी कहीं ज्यादा हैं
    • कई साल तक Btrfs इस्तेमाल किया और कुछ साल पहले उसे छोड़ दिया
      Btrfs में भी एक-दो बार अजीब चीजें हुईं, लेकिन आखिर में सब recover किया जा सका
      कुल मिलाकर Btrfs की flexibility अच्छी थी, लेकिन ज्यादातर मामलों में यह बहुत धीमा लगा
      अब Arch Linux पर ZFS इस्तेमाल कर रहा/रही हूँ और अभी तक कुल मिलाकर कोई समस्या नहीं है
      performance optimize करने के लिए customization और तरीके भी ज्यादा हैं
      एक सलाह दूँ तो ZFS को अच्छी तरह research और test करना बेहतर है। learning curve थोड़ा है, लेकिन मेरे लिए switch करना worthwhile रहा

  • NVMe performance के लिए ARC bypass आना अच्छी बात है
    ZFS आम तौर पर NVMe की क्षमता का पूरा फायदा नहीं उठा पाता
    online expansion भी दिलचस्प हो सकता है
    बहुत व्यस्त database पर ZFS इस्तेमाल करने की कोशिश की थी, लेकिन fragmentation bug ने बुरी तरह परेशान किया
    performance वापस लाने का एकमात्र तरीका ऐसा लग रहा था कि data को volume से बाहर copy करें, volume हटाएँ, फिर वापस copy करें
    अब शायद zpool expand करने के बाद उसी volume के अंदर tablespace copy करके fragmentation कम की जा सके

  • यह भी देखने लायक है कि TrueNAS पहले से इस feature को support करता है[0]
    शायद यह 2.3.0rc3 इस्तेमाल कर रहा है, stability के बारे में निश्चित नहीं, लेकिन बहुत उत्सुक हूँ
    https://www.truenas.com/blog/electric-eel-openzfs-23/

  • क्या कोई समझा सकता है कि घरेलू इस्तेमाल के लिए ZFS जैसी चीज़ क्यों इस्तेमाल की जाए?

    • मेरे लिए इसके अच्छे कारण ये हैं
      checksum: घरेलू इस्तेमाल में आम तौर पर hardware quality कम होती है, इसलिए यह उल्टा और भी ज़रूरी हो जाता है। खराब controller, घटिया cable, recommended से ज़्यादा तापमान पर रखे hard disk वगैरह—गलत data save होने की वजहें बहुत हैं, और अगर redundancy हो तो ZFS इसे अच्छी तरह अपने-आप संभाल लेता है
      snapshot: backup बनाने और गलती होने पर file के पुराने version पर जल्दी लौटने के लिए बहुत उपयोगी
      मन की शांति: alternatives की तुलना में मुझे लगता है कि ZFS इस्तेमाल में आसान है और ऐसी गलतियाँ करना मुश्किल है जिनसे data loss हो। उदाहरण के लिए, खराब drive बदलते समय अगर गलती से गलत drive निकाल दें और pool usable न रहे, तो वापस लगाने पर वह ऐसे लौट आता है जैसे कुछ हुआ ही न हो
      अब शायद mdadm भी अलग हो, लेकिन कुछ साल पहले जब मैंने इसे इस्तेमाल किया था, तो destructive गलती हो जाने का डर हमेशा बना रहता था
    • ऐसा जवाब दूँ जो दूसरों ने नहीं दिया: ZFS Steam game storage के लिए अच्छा है
      recordsize=1M और compression=zstd set करने पर अक्सर उतनी ही जगह में करीब 33% ज़्यादा games store किए जा सकते हैं
      मेरा एक दोस्त कुछ hard disks पर Steam games store करने के लिए ZFS इस्तेमाल करता है। और उसने ZFS को SSD L2ARC के रूप में दिया है
      ZFS अक्सर चलाए जाने वाले games को अपने-आप SSD में cache कर देता है, जिससे वे तेज़ी से load होते हैं
      पसंदीदा games बदलने पर ZFS अपने-आप adapt करके उन games को SSD में cache कर देता है
    • zrepl का इस्तेमाल करके पूरे file system को हर 10 मिनट में local NAS पर replicate करता हूँ
      जब WD_BLACK SN850 अचानक मर गया था [1], तब यह पहले ही एक बार बहुत काम आया था
      classic git गलती से उड़ाया गया code भी इससे recover हो गया था
      user की गलती या single device failure से data खोना अब संभव नहीं होना चाहिए। हमारे पास वह technology है
      [1]: https://chromakode.com/post/zfs-recovery-with-zrepl/
    • वजहें कई हैं, लेकिन मेरे लिए बड़ी वजहें reliability और portability हैं
      checksum और self-healing है, और कोई दूसरा modern file system नहीं है जिसे Linux, FreeBSD, Windows, macOS पर read और write किया जा सके
      snapshot, यानी boot environment, Btrfs भी support करता है। मेरा Linux install root file system पढ़ने के लिए third-party kernel module की चिंता न करनी पड़े इसलिए वही इस्तेमाल करता है
      performance भी बहुत बढ़िया नहीं है, और Linux के हिसाब से अगर performance मुख्य चिंता है तो XFS बेहतर choice है
    • अपेक्षाकृत आसान, लेकिन powerful है
      इससे पहले मैं MDADM + LVM + dm-crypt + ext4 इस्तेमाल करता था और वह भी चलता था, लेकिन layers इतनी ज़्यादा थीं कि सिरदर्द हो जाता था
      automatic snapshots बहुत आसान और तेज़ हैं
      file delete होने पर access करना भी आसान है, इसलिए पूरा snapshot restore करने की ज़रूरत नहीं; hidden .zfs/ folder से बस cp कर सकते हैं
      कई साल से 8TB की 6 disks के साथ चला रहा हूँ। RAIDZ2 है, इसलिए maximum 2 disks तक fail हो सकती हैं
      अगर पूछें कि क्या desktop की single disk पर इसे इस्तेमाल करूँगा, तो शायद नहीं करूँगा