मैंने चार विक्रेताओं के चार NVMe SSDs का परीक्षण किया – पावर लॉस पर आधे FLUSH किया हुआ डेटा खो देते हैं (2022)

मूल लेख ↗ Hacker News चर्चा ↗

Consumer NVMe SSDs पर किए गए परीक्षण दिखाते हैं कि कुछ ड्राइव पावर लॉस के बाद हाल ही में लिखा गया डेटा खो देते हैं, भले ही operating system ने FLUSH command जारी की हो और उसे बताया गया हो कि डेटा सुरक्षित रूप से संग्रहीत है। थ्रेड उन विशिष्ट models की पहचान करता है जो इन durability checks में असफल या सफल रहे, यह समझाता है कि firmware और controller design के निर्णय vendors को डेटा committed होने के बारे में “झूठ” बोलने की ओर कैसे ले जा सकते हैं, और consumer hardware की enterprise drives से तुलना करता है जो power-loss protection के लिए capacitors का उपयोग करती हैं। टिप्पणीकार standards compliance, बाजार में fake और downgraded SSDs, और storage devices के अविश्वसनीय होने पर file systems तथा applications वास्तव में डेटा की रक्षा के लिए क्या कर सकते हैं, इस पर कानूनी और व्यावहारिक प्रश्न भी उठाते हैं.

परीक्षण किए गए ड्राइव और परिणाम

  • शुरुआती ट्वीट में चार NVMe SSDs का परीक्षण किया गया; रिपोर्ट किए गए FLUSH पूर्ण होने के बावजूद दो ने डेटा खो दिया।
  • बाद में थ्रेड में एक बड़ी सूची दिखाई देती है (उस समय तक कुल 12 का परीक्षण हुआ):
    • FLUSH परीक्षण में पास बताए गए ड्राइव:
      Samsung 970 Evo Plus 2TB, WD Red SN700 1TB, Crucial P2 250GB, Samsung 980 250GB, WD Black SN750 1TB, WD Green SN350 240GB.
    • फेल बताए गए ड्राइव (FLUSH + पावर लॉस के बाद डेटा खो गया):
      SK Hynix Gold P31 2TB (विशिष्ट FW संस्करण), Sabrent Rocket 512GB (Phison-आधारित)।
  • टिप्पणीकार नोट करते हैं कि जब और ड्राइव का परीक्षण किया गया तो शीर्षक में “आधा” पुराना हो गया (2/12, न कि 2/4), और यह परीक्षण 2022 की शुरुआत का है।

FLUSH semantics, PLP, और firmware behavior

  • NVMe FLUSH से अपेक्षा की जाती है कि वह पूरा होने से पहले सभी पूर्व लिखतें non-volatile media पर सुरक्षित हो जाएँ।
  • यह अंतर बताया गया है कि:
    • ड्राइव ईमानदारी से पूर्णता को तब तक विलंबित करें जब तक डेटा सुरक्षित न हो।
    • ड्राइव झूठ बोलें, यानी डेटा अभी भी volatile/cache में होने पर भी जल्दी पूर्णता दिखाएँ।
  • चर्चा इस बात पर जोर देती है कि यह power-loss capacitors के विफल होने के बारे में नहीं है, बल्कि flush contract का उल्लंघन है।
  • enterprise SSDs आमतौर पर power-loss protection (PLP) capacitors का उपयोग करते हैं; consumer drives प्रायः नहीं करते।
  • कुछ लोगों का तर्क है कि यदि कोई drive FLUSH को सुरक्षित रूप से सम्मानित नहीं कर सकती (या बहुत छोटे flushes के साथ दुरुपयोग हो रहा है), तो उसे धीमा होना चाहिए या errors लौटाने चाहिए, झूठ नहीं बोलना चाहिए।

Filesystems, corruption के लक्षण, और वास्तविक प्रभाव

  • कई रिपोर्टों में crash या power loss के बाद फाइलें पूरी तरह zero हो जाने की बात है (logs, configs, cache files, project metadata)।
  • बहस इस पर है कि zeroed files कहाँ से आती हैं:
    • खराब व्यवहार करने वाली drives जो flush/fua semantics की अनदेखी करती हैं, या
    • filesystem behavior (ext4 delayed allocation, journaling modes, TRIM का unallocated space के लिए zeros लौटाना, गलत fsync usage)।
  • सहमति: journaling filesystems (NTFS, ext4) metadata की रक्षा करते हैं, लेकिन यदि underlying drive झूठ बोलती है तो data की रक्षा नहीं कर सकते।

Consumer vs enterprise drives और performance tradeoffs

  • कई टिप्पणियाँ सस्ते NVMe SSDs का वर्णन करती हैं:
    • मज़बूत short-burst benchmarks, लेकिन बहुत खराब sustained performance और/या sync performance।
    • SLC caches और QLC/TLC behavior पर भारी निर्भरता।
  • कुछ लोग critical data या sync-heavy workloads के लिए केवल enterprise/PLP SSDs के उपयोग की सिफारिश करते हैं; अन्य लोग जोर देते हैं कि consumer drives को भी standards का उल्लंघन नहीं करना चाहिए।

Trust, regulation, और ecosystem issues

  • चिंताएँ:
    • विक्रेताओं का review के बाद components बदलना।
    • standards का झूठा या अधूरा पालन।
  • सुझावों में recalls, small-claims actions, false-advertising enforcement को मजबूत करना, और समुदाय-रखरखाव वाली “known good/bad” hardware lists शामिल हैं।