ZFS की बदौलत डेटा लॉस सिर्फ 10 मिनट तक सीमित रहा

 (mastodon.social)
3 पॉइंट द्वारा GN⁺ 2023-08-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 2 साल पुराना SSD अचानक खराब हो गया, लेकिन ZFS incremental replication से सिस्टम को नई ड्राइव पर फिर से चालू किया गया और वास्तविक नुकसान लगभग 10 मिनट का ही रहा
  • पूरा filesystem हर 10 मिनट में snapshot लेकर NAS पर भेजा जाता था, और automation के लिए zrepl का उपयोग किया गया
  • snapshot चल रहे सिस्टम की किसी खास समय-बिंदु की स्थिति सहेजते हैं और सिर्फ बदला हुआ हिस्सा भेजते हैं, इसलिए home network पर भी background replication संभव रही
  • restore प्रक्रिया में 625GiB ZFS receive को रात भर चलाना पड़ा और encryption wrapper key भी बहाल करनी पड़ी, इसलिए यह automatic recovery से काफी दूर थी
  • ZFS को शुरू में अपनाने और उसके maintenance का बोझ बड़ा है, लेकिन वास्तविक drive failure के समय इसने काम की स्थिति तक वापस लाने वाला disaster recovery प्रभाव दिखाया

SSD खराब होने के बाद बचा नुकसान सिर्फ 10 मिनट

  • जैसे ही लेखक ने laptop खोलकर email भेजने की कोशिश की, स्क्रीन काली होकर अटक गई, और reboot के बाद पता चला कि 2 साल पुराना SSD खराब हो चुका है
  • नई ड्राइव पर सिस्टम restore करने के बाद मशीन फिर से उपयोग योग्य हो गई, और कुल data loss लगभग 10 मिनट का रहा
  • बहाल हुआ laptop वहीं से boot हुआ जहाँ काम रुका था, और browser tabs ने पिछली रात का अधूरा काम भी फिर से सामने ला दिया
  • 12 साल पुराने Chromebook विज्ञापन की तरह, नए device पर पुरानी स्थिति से काम जारी रखने का विचार इस failure में सचमुच काम कर गया

बैकअप से ज़्यादा replication के करीब संरचना

  • सिर्फ drive backup करने के बजाय पूरे filesystem replication का तरीका अपनाया गया
  • पिछले सर्दियों में creative work वाले computers के नियमित backup के लिए home network storage बनाया गया, और कई विकल्पों में से ZFS incremental replication चुना गया
  • ZFS चल रहे सिस्टम पर भी किसी खास समय का snapshot कुशलता से बना सकता है
  • इसके बाद दूसरी machine पर भेजते समय पूरा data बार-बार भेजने के बजाय सिर्फ बदला हुआ data भेजा जाता है

zrepl से हर 10 मिनट में NAS पर ट्रांसफर

  • snapshot बनाना और NAS पर भेजना automate करने के लिए zrepl का उपयोग किया गया
  • configuration ऐसी थी कि पूरा filesystem हर 10 मिनट में snapshot लेकर भेजा जाता था
  • incremental snapshot की वजह से home network पर background में चलते हुए भी replica को up to date रखा जा सकता था
  • आखिरी run में transfer में 14 सेकंड लगे और लगभग 64MiB भेजा गया

restore प्रक्रिया में सामने आया manual काम का बोझ

  • system restore एक ऐसा process था जिसे सीखना पड़ता है, और इसका बड़ा हिस्सा manual work पर निर्भर था
  • 625GiB ZFS receive का काम रात भर चलाना पड़ा
  • snapshot इस तरह थे कि source computer ने उन्हें encrypted रखा था, इसलिए NAS उनकी सामग्री पढ़ नहीं सकता था
  • backup को वास्तव में उपयोग करने के लिए encryption wrapper key भी restore करनी पड़ी
  • data को decrypt कर पाने की पहली पुष्टि मिलने तक restore प्रक्रिया बहुत अस्थिर और चिंताजनक लगी

अपनाने की लागत और hardware replacement

  • ZFS की शुरुआती setup में पूरा filesystem बदलना पड़ता है, इसलिए शुरुआती लागत अधिक थी
  • maintenance के लिए काफी विशेषज्ञता चाहिए और ऐसे operational procedures भी आते हैं जिनमें manual काम शामिल होता है
  • फिर भी SSD के पहली बार खराब होने से पहले replication सेट कर लेना सौभाग्य रहा, और इस मामले में ZFS के फायदे साफ दिखे
  • खराब हुई drive मूल Framework order के साथ आई WD_BLACK SN850 थी
    • Framework forum पर इस drive के अचानक मर जाने या boot न होने के परेशान करने वाले मामले पहले देखे गए थे
  • उसी दिन Amazon से SK Hynix P41 SSD और Sabrent NVMe enclosure लगभग 3 घंटे में डिलीवर हो गए

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

1 टिप्पणियां

 
GN⁺ 2023-08-24
Hacker News की टिप्पणियां

  • ZFS इस्तेमाल कर रहे हैं, इसलिए दूसरे WD या SanDisk SSD users के मुकाबले तैयारी बेहतर ही मानी जाएगी
    https://petapixel.com/2023/08/08/sandisk-portable-ssds-are-failing-so-frequently-we-can-no-longer-recommend-them/
    https://www.theverge.com/22291828/sandisk-extreme-pro-portable-my-passport-failure-continued
    https://news.ycombinator.com/item?id=37042587
    https://www.theverge.com/23837513/western-digital-sandisk-ssd-corrupted-deleted-questions
    https://news.ycombinator.com/item?id=37188736

    • मिरर किए गए zpool की दो डिस्क कभी सिर्फ 8 मिनट के अंतर से fail हो गई थीं
      दोनों HGST थीं और वह सचमुच दुखद दिन था, लेकिन शुक्र है कि दूसरी location पर नियमित रूप से zfs send किया हुआ था, इसलिए data loss बहुत कम हुआ। ZFS कमाल है
    • यह The Verge द्वारा https://www.theverge.com/22291828/sandisk-extreme-pro-portable-my-passport-failure-continued में शिकायत किए गए Google search problem से भी थोड़ा जुड़ता है
      कहा जाता है कि Google “4TB SanDisk SSD” जैसे search terms को product page खोजने के तौर पर मानता है, इसलिए The Verge या Ars Technica के articles जैसी खबरें search results में काफी नीचे धकेल दी जाती हैं। मैं paid search engine Kagi को test कर रहा था, इसलिए यह देखने का अच्छा मौका था कि क्या किसी अलग तरह की web search से अलग results मिल सकते हैं, लेकिन अगर पूरा web तारीफ वाले posts से भरा हो, तो priority rules अलग होने पर भी अलग results दिखाना मुश्किल लगता था
      पहले 5–6 results shopping sites हैं, उसके बाद easeus [1], techpowerup [2], anandtech [3], consumerreviews [4] की reviews आती हैं, लेकिन इनमें से किसी में भी “fail” शब्द शामिल नहीं है। आखिर में, Google से बेहतर एकमात्र बात यह है कि “sandisk 4tb ssd failure”, “sandisk 4tb ssd problems” जैसे related search suggestions हैं; वे page के बिल्कुल नीचे हैं इसलिए दिखना मुश्किल है, लेकिन Google के first results page पर “fail” बिल्कुल न दिखने से तो बेहतर है
      [1]: https://www.easeus.com/knowledge-center/sandisk-4tb-extreme-portable-ssd-v2-full-review.html
      [2]: https://www.techpowerup.com/review/sandisk-ultra-3d-4-tb-ssd/
      [3]: https://www.anandtech.com/show/16892/sandisk-extreme-pro-crucial-x6-4tb-portable-ssds
      [4]: https://consumerreviews.store/sandisk-4tb-extreme-portable-ssd-up-to-1050mb-s-usb-c-usb-3-2-gen-2-review/

  • Linux दुनिया को पूरी तरह छोड़ने से ठीक पहले मैंने btrfs नाम के हिमखंड को थोड़ा-थोड़ा खंगालना शुरू किया था, और वह काफ़ी दिलचस्प लगा
    बैकअप में नएपन, डिस्क कॉन्फ़िगरेशन वगैरह कई फीचर्स में इसकी संभावना बड़ी दिखी। btrfs, ZFS नहीं है, लेकिन फीचर्स में कुछ ओवरलैप है और यह “गरीब आदमी का ZFS” जैसा भी है। साथ ही ZFS की licensing, packaging और kernel में शामिल होने की स्थिति थोड़ी अस्पष्ट है, इसलिए कुछ operating systems में btrfs कहीं ज़्यादा व्यावहारिक ढंग से चलता है
    Linux User Group में मैंने बताया था कि कंप्यूटर reboot करने के लिए मुझे power cord निकालनी पड़ी, तो उस मूर्खतापूर्ण हरकत के लिए मुझे खूब डांट पड़ी और ZFS इस्तेमाल करने की सलाह मिली। हालांकि यह देखते हुए कि वह system Raspberry Pi था, यह सोचना बदल सकता है कि दोनों में से कौन-सा काम ज़्यादा समझदारी वाला था

    • Pi में filesystem corruption हो सकता है, ऐसा कहा जाता है, लेकिन image install करते समय हर बार मैं जगह-जगह tmpfs mount करने और ज़्यादातर बेकार logs बंद करने वाली script चलाता हूं, इसलिए मैंने खुद ऐसा होते नहीं देखा
      जब तक SD card को बहुत ज़्यादा न घिसा जाए, ये devices बहुत stable ढंग से चलते रहते हैं। ZFS वाकई शानदार दिखता है, लेकिन अगर कभी NAS खरीदूं भी, तो शायद ऐसे hardware पर पैसा खर्च नहीं करना चाहूंगा जो ZFS चला सके, इसलिए शायद RAID और ext4 ही इस्तेमाल करूंगा
      btrfs से मैं इसलिए बचता रहा क्योंकि हर कुछ महीनों में “BTRFS ने मेरा data उड़ा दिया” जैसी posts दिखती थीं, और फिर इस पर बहस चलती थी कि गलती btrfs की थी या नहीं। अब ऐसी posts कम दिखती हैं, तो शायद फिर से देखने का समय आ गया है
    • जिज्ञासा है, Linux दुनिया को पूरी तरह छोड़ने की वजह क्या थी? “community” दूसरों के लिए बेहतर बने, इसके लिए उस अनुभव से क्या सीखा जा सकता है?
    • btrfs में सच में जो एकमात्र चीज़ मुझे पसंद नहीं है, वह है कि इसमें fragmentation आसानी से हो जाता है
      खासकर sparse VM images में ऐसा होता है, और उस use case के लिए मुझे zvol कहीं बेहतर लगता है

  • कुछ साल पहले capacitor plague था, अब लगता है storage devices की महामारी झेल रहे हैं
    सभी storage devices का लगातार खराब होते जाना बेतुका होता जा रहा है। WD, SMR से HDDs खराब कर रहा है, और manufacturers कह रहे हैं कि SSD और HDD का 3 साल का uptime पहले ही बहुत लंबा है—और यह मज़ाक नहीं है। इस साल ही मेरा एक Kingston SSD मर गया; वह करीब 8 साल पुराना था, तो मान लिया, लेकिन portable WD HDD भी करीब 2 साल में मर गया
    आजकल internet data loss और lifespan की समस्याओं से भरा है। 20 साल पहले HDD भी हमेशा चलने वाली चीज़ नहीं थे, लेकिन मुझे याद है कि वे कम से कम उस computer की useful life से तो निश्चित रूप से ज़्यादा चलते थे जिसके साथ खरीदे गए थे

    • आजकल के hard disks 20 साल पहले की तुलना में कहीं ज़्यादा भाग्यशाली रहे हैं
      20 साल पहले बदनाम IBM Deathstar drives का दौर था, जिनमें magnetic coating सचमुच platter से उतर जाती थी। 1–2 साल में मर जाने वाली भयानक Maxtor drives भी थीं, और Seagate ने Maxtor को acquire करने के बाद कुछ समय तक Seagate drives भी अस्थिर हो गई थीं। करीब 8 disks वाले server चलाते हुए मुझे हर साल लगभग एक drive बदलनी पड़ती थी
      इसके उलट, अब मैं 20 से ज़्यादा drives वाले ZFS server के management में मदद करता हूं, और drives की उम्र लगभग 4–5 साल है। साथ ही उस समय computers कहीं जल्दी पुराने पड़ जाते थे। आज 6 साल पुराना computer भी काफ़ी इस्तेमाल लायक है, लेकिन तब 3 साल पुराना computer भी काफी पुराना महसूस होता था
    • चिंता करने की ज़रूरत नहीं। जल्द ही chips भी कुछ सालों बाद गड़बड़ करने लगेंगे
      हम scaling limit से टकरा रहे हैं, और exponential growth धीमी हो रही है
    • निजी तौर पर मुझे याद है कि पहले भी मेरे और आसपास के लोगों के HDD कभी-कभी खराब हो जाते थे
      अब SSD में ऐसा लगभग नहीं होता। यहां तक कि 2000s के late दौर के पुराने Intel SSD, जो problems के लिए जाने जाते थे, अभी भी उसी पुराने MacBook में ठीक चल रहे हैं जिसे मैंने कुछ साल इस्तेमाल करने के बाद अपनी मां को दे दिया था। असल data की हालत कैसी होगी, यह जानने की जिज्ञासा है
    • पिछले 10 सालों में खरीदी गई सभी WD drives उम्मीद के मुताबिक चलीं। इसमें SMR आने के बाद खरीदी गई NAS वाली drives भी शामिल हैं, क्योंकि मैंने यह सुनिश्चित किया कि वे सिर्फ Red नहीं, बल्कि Plus या Pro हों
      SSD के साथ भी किस्मत अच्छी रही, लेकिन desktop में मैं अब भी /home directory और RAID array पुराने spinning drives पर रखता हूं, इसलिए सिर्फ छोटा SSD इस्तेमाल करता हूं
      दो exceptions थीं। SMR से पहले की दो WD Red drives को बड़े disks से बदलने के लिए पुराने NAS से निकाला, वे पूरी तरह ठीक थीं, और anti-static bags में रखकर drawer में रख दीं। करीब 2.5 साल बाद spare disk की ज़रूरत पड़ी, तो निकालकर देखा कि दोनों काम नहीं कर रही थीं; एक पूरी तरह मर चुकी थी और दूसरी मुश्किल से detect होती थी लेकिन पढ़ी नहीं जा सकती थी। पहली को connect करने पर वह बिल्कुल दिखाई नहीं दी, और controller PCB pins समेत सभी contacts साफ़ करके भी फायदा नहीं हुआ, इसलिए आखिरकार उसे फेंक दिया। दूसरी पूरी तरह reformat करने के बाद ही फिर इस्तेमाल हो पाई, लेकिन testdisk इस्तेमाल करने पर भी पुराना data recover करने का कोई तरीका नहीं था। ऐसा मैंने न कभी अनुभव किया था न उम्मीद की थी, इसलिए सच कहूं तो यह काफी चिंताजनक है
    • करीब 20 साल पहले भी HGST “Deathstar” था, और वह इतना खराब drive था कि उस पर class-action lawsuit तक हुआ था
      disks हमेशा random तरीके से मरती रही हैं, और Sun ने ZFS बनाने के कारणों में से एक यही था

  • बहुत संक्षेप में कहें तो, Mastodon thread https://zrepl.github.io की ओर इशारा कर रहा है
    “zrepl, ZFS replication के लिए एक integrated one-stop solution” है

    • zrepl Go में लिखा है और sanoid/syncoid Perl scripts हैं—इसके अलावा क्या किसी को पता है कि zrepl और sanoid/syncoid में क्या फर्क है?
    • लगता है कि storage server पर चल रहे daemon से communicate करना पड़ता है
      उदाहरण के लिए अगर S3 को सीधे storage के रूप में इस्तेमाल किया जा सके तो शानदार होगा

  • Zrepl एक बड़ा कारण है कि मैं digital nomad life निश्चिंत होकर जी पाता हूं
    हर रात लगभग एक बार चलने वाली script अलग header वाले LUKS-protected ZFS pool को खोलती है और सभी snapshots copy करती है। वह NVME enclosure हमेशा मेरे शरीर से दूर न होने वाले “bag” में रहता है
    इस setup और NixOS की वजह से मैं लगभग 10 मिनट में वैसा ही नया laptop provision कर सकता हूं। हाल ही में offsite replication भी जोड़ा है, इसलिए अगर मुझसे पूरी तरह बुरी तरह लूटपाट भी हो जाए, तो गंभीर data loss की संभावना लगभग 0 के करीब है
    Zrepl वाकई बेहतरीन software है। शुरू करना आसान है, लेकिन जरूरत पड़ने पर हर tuning knob को छू सकने जितना sophisticated और powerful है। इसकी तारीफ कम पड़ जाती है

    • चोरी, आग, बाढ़ या किसी और disaster की एक घटना से ही सब खत्म हो जाने वाले ज़्यादातर लोगों की तुलना में यह काफी ज़्यादा सुरक्षित लगता है
    • क्या आपने sanoid/syncoid इस्तेमाल किया है? उनके मुकाबले Zrepl क्या अतिरिक्त देता है?
    • अच्छा होगा अगर आप लिखें कि यह setup कैसे काम करता है। काफी दिलचस्प सुनाई देता है

  • क्या filesystem का हर 10 मिनट में snapshot लेना SSD के मरने की वजह बन सकता था?

    • ZFS खास है, और copy-on-write इस्तेमाल करता है, इसलिए snapshot बनाने की लागत कम होती है
      सहज तौर पर लगता है कि बहुत बार snapshot लेने पर भी अतिरिक्त writes काफी कम होंगे। फिर भी कोई scientific measurement हो तो अच्छा होगा
      पहले जिन कुछ servers को मैं manage करता था, उन पर ZFS में हर मिनट, हर घंटे और हर दिन snapshots लेता था। minute-level snapshots 60 मिनट बाद delete कर देता था, और दूसरी machine के cron job से hourly और daily snapshots का backup लेता था। hourly snapshots लगभग 72 घंटे रखता था, और daily snapshots permanent रखने के लिए सेट किए थे। minute-level snapshots का मकसद SQL migrations के दौरान manual mistakes को undo करना था, और यह अच्छी तरह काम करता था
      अब भी FreeBSD server पर ZFS इस्तेमाल करता हूं, लेकिन मौजूदा projects में traffic कम है और important data changes भी rare हैं, इसलिए personal server पर लगभग हफ्ते में 1 बार manually snapshot लेता हूं और दूसरे server से backup manually trigger करता हूं। साथ ही अब सिर्फ PostgreSQL database और application data वाले filesystem हिस्से का snapshot लेता हूं। operating system data की अब उतनी चिंता नहीं करता। कोई serious hardware failure हो जाए तो OS fresh install कर लूंगा, important settings लिखकर रखता हूं, और backup script चलते समय बाकी इधर-उधर की चीजों के बजाय उन्हीं values को copy करने के लिए सेट किया है
    • इसकी संभावना कम है
      snapshots ज्यादा writes नहीं करते, और SSD तथा ZFS दोनों ही copy-on-write तरीके के हैं। यानी snapshot के बाद write cost snapshot से पहले जैसी ही रहती है
      हालांकि context missing है। SSD और ZFS दोनों को full या लगभग full हालत पसंद नहीं होती। अगर working data करीब 650GB था और drive 1TB की थी, तो snapshots की वजह से drive usage आसानी से 90% से ऊपर गया होगा। इतना ही ZFS को परेशान करने के लिए काफी हो सकता है
    • मेरी समझ के मुताबिक ZFS में snapshot लेना metadata object और कुछ data references लिखना है
      मान लें data 100GB है, block size 128K है, और pointer 64-bit है, तो snapshot के दौरान नया लिखा जाने वाला data लगभग 5MB के आसपास होगा। इसे घंटे में 6 बार, साल में 52,560 बार करने से drive जल्दी घिसने जितना असर होगा या नहीं, देखें तो यह सालाना लगभग 256GB है। यह SSD write endurance के 1% से कम होने की संभावना है। इसलिए अगर 10-minute snapshots महत्वपूर्ण वजह हों तो मुझे हैरानी होगी
      मैं गलत भी हो सकता हूं, और यह estimate बहुत भरोसेमंद न लगने वाले स्रोतों की मदद से निकाला है। corrections welcome हैं। फिर भी अगर मेरा estimate असल से ज्यादा है, और तब भी lifespan पर असर पड़ने की संभावना कम है, तो point खुद ही शायद ज्यादा मायने न रखे
    • संभावना कम है। snapshot मोटे तौर पर सबसे हाल में लिखे गए blocks को mark करता है और पुराने blocks को बदलने से रोकता है
      ZFS copy-on-write है, इसलिए file changes में वही writes होते हैं, बस कुछ existing data delete नहीं होता
    • किसी random orange website के comment[1] के मुताबिक modern flash chips का minimum write size करीब 100MB हो सकता है
      तब हर 10 मिनट में 5MB write असल में घंटे में 600MB, 8-hour workday के हिसाब से 4.8TB, 40-hour week के हिसाब से 24TB बन जाता है, और 1TB drive पर real-time 3.43 DWPD, 2 साल real-time में 2500TBW हो जाता है[2]
      SN850 की official write endurance 600TBW है, लेकिन warranty issues की वजह से जाहिर है यह conservative रूप से कम किया गया आंकड़ा हो सकता है। संयोग से 2500TB इस market के कई SSDs में आम endurance number भी है। कुल मिलाकर यह पूरी तरह असंभव बात नहीं लगती
      अगर अभी भी जिंदा है तो controller SMART data में क्या कहता है, यह जानने की उत्सुकता है। Linux में apt install smartmontools; smartctl -s on /dev/sda; smartctl -A /dev/sda चलाने पर table output होगा[4]. Windows में CrystalDiskInfo[3] install कर लें
      1: https://news.ycombinator.com/item?id=29165202
      2: DWPD: drive writes per day, TBW: Total Bytes Written - in terabytes
      3: https://crystalmark.info/en/software/crystaldiskinfo/
      4: “Pre-fail” का मतलब है कि failure से ठीक पहले value बदलनी चाहिए, और “Old_age” का मतलब है कि यह age दिखाने वाली value है; इसका मतलब “यह खराब है और जल्द fail होगा” या “यह drive पुरानी है” नहीं है। हमेशा हर item में Pre-fail और Old_age दिखते हैं। मुझे लगता है बहुत पहले किसी को इन्हें “somewhat_boolean” और “life_remain” में बदल देना चाहिए था

  • मैं आमतौर पर Apple Time Machine incremental backup Synology rotating disk server पर करता हूं
    risky काम करते समय या machine upgrade करते वक्त कभी-कभी external SSD पर internal drive को mirror भी कर लेता हूं। यह तरीका अच्छी तरह काम करता है। Time Machine restore काफी slow हो सकता है, लेकिन ज्यादातर important data Git और hosted repositories में है, इसलिए बड़ी समस्या नहीं रही। किसी single file को rollback करना हो तो कभी-कभी Time Machine इस्तेमाल करता हूं
    मेरे पास बदनाम[0] SanDisk drive भी है, लेकिन उसे किसी critical काम में इस्तेमाल नहीं करता। उसमें बस games storage जैसा कुछ है। Mac user होने के नाते games बड़ा factor नहीं हैं, और वे मर भी जाएं तो मैं रोऊंगा नहीं
    [0] https://arstechnica.com/gadgets/2023/08/sandisk-extreme-ssds-are-worthless-multiple-lawsuits-against-wd-say/

    • मैं भी Time Machine इस्तेमाल करता हूं। https://tclementdev.com/timemachineeditor/ app लिया और जब भी machine idle हो, तब manually TM backup trigger कराने के लिए set किया
      Apple के automatic backups या time-based backups से यह कहीं बेहतर काम करता लगता है
    • मैंने Time Machine छोड़ दिया। Synology पर atalk वगैरह इस्तेमाल करने पर भी यह शायद ही कभी एक-दो महीने से ज्यादा ठीक से चला

  • मेरे snapshots मूल कंप्यूटर पर encrypted हैं। यह अच्छी बात है कि NAS उन्हें पढ़ नहीं सकता
    इसलिए backup इस्तेमाल करने के लिए encryption wrapper key भी restore करनी पड़ी। सच कहूं तो, जब तक पहली बार यह पुष्टि नहीं हो गई कि data decrypt किया जा सकता है, तब तक काफी डर लग रहा था
    custom backup तरीके को तब तक काम कर रहा मानकर नहीं चलना चाहिए, जब तक आप समय-समय पर सच में data restore कर सकते हैं या नहीं, यह verify न कर लें

    • non-custom backups पर भी यही बात लागू होती है
    • मैं हमेशा सोचता रहा था कि एहतियात के तौर पर LUKS header की एक copy अलग disk पर रखनी चाहिए

  • यहां Linux का निकट भविष्य bcachefs है
    https://bcachefs.org/

    • bcachefs, BTRFS या ZFS से बेहतर क्या करता है?
    • निकट भविष्य कहना थोड़ा अजीब है, क्योंकि इसे develop होते हुए पहले ही 7 साल हो चुके हैं और यह अभी तक upstream में accept नहीं हुआ है
      हालांकि upstream में merge कराने का काम जारी है
    • क्या कोई छोटा summary है कि इससे उम्मीद क्यों रखनी चाहिए? क्या इसमें कोई शानदार features हैं?

  • “जब तक पहली बार यह पुष्टि नहीं हो गई कि data decrypt किया जा सकता है, तब तक काफी डर लग रहा था” से ऐसा लगता है कि procedure को उतना test और document नहीं किया गया था जितना होना चाहिए था
    home systems या personal desktops में यह बहुत दुर्लभ बात नहीं है। फिर भी production server पर आप restore procedure को मौके पर improvisation करके समझना नहीं चाहेंगे

    • सही। मुझे पता था कि restore के लिए जरूरी सारी चीजें मेरे पास हैं, और 6 महीने पहले एक बार test भी किया था, लेकिन शुरुआत में मैंने गलत key copy कर ली थी
      load fail होने पर कुछ देर के लिए बहुत निराशा हुई, लेकिन जल्द ही गलती समझ आ गई। ऐसे failure के पलों में हर process की कमियां चकाचौंध कर देने वाली clarity के साथ सामने आ जाती हैं