1. फ्लैश आधारित भंडारण
क्या यह डिस्क प्रकार (पारंपरिक हार्ड ड्राइव बनाम ठोस-राज्य डिस्क) या किसी अन्य चर पर निर्भर करता है, जिसके बारे में मुझे जानकारी नहीं है? क्या यह होता है (यदि यह करता है) केवल लिनक्स में या यह अन्य OSes में मौजूद है?
जब आपके पास एक विकल्प होता है, तो आपको फ्लैश-आधारित भंडारण को बिना शटडाउन के बिजली खोने की अनुमति नहीं देनी चाहिए।
एसडी कार्ड की तरह कम लागत वाले भंडारण पर, आप पूरे इरेज़-ब्लॉक (4KB से कई गुना बड़ा) खोने की उम्मीद कर सकते हैं, डेटा खो सकते हैं जो विभिन्न फाइलों या फाइल सिस्टम की आवश्यक संरचनाओं से संबंधित हो सकते हैं।
बिजली की विफलता के कारण कुछ महंगे एसएसडी बेहतर गारंटी देने का दावा कर सकते हैं। हालांकि तीसरे पक्ष के परीक्षण से पता चलता है कि कई महंगे एसएसडी ऐसा करने में विफल रहते हैं। "पहनने लेवलिंग" के लिए ब्लॉक को हटाने वाली परत जटिल और मालिकाना है। संभावित विफलताओं में ड्राइव पर सभी डेटा का नुकसान शामिल है।
हमारे परीक्षण ढांचे को लागू करते हुए, हम कुल तीन हजार से अधिक गलती इंजेक्शन चक्रों का उपयोग करते हुए छह अलग-अलग विक्रेताओं से 17 कमोडिटी एसएसडी का परीक्षण करते हैं। हमारे प्रयोगात्मक परिणामों से पता चलता है कि 17 में से 14 परीक्षण किए गए एसएसडी डिवाइस बिजली के दोषों के तहत आश्चर्यजनक विफलता व्यवहार प्रदर्शित करते हैं, जिसमें थोड़ा भ्रष्टाचार, कटा हुआ लेखन, अप्राप्य लेखन, मेटाडेटा भ्रष्टाचार और कुल डिवाइस विफलता शामिल हैं।
2017: https://dl.acm.org/citation.cfm?id=2992782&preflayout=flat
2013: https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf?wptouch_preview_theme=enabled
2. हार्ड डिस्क ड्राइव को स्पिन करना
स्पिनिंग एचडीडी की अलग-अलग विशेषताएं हैं। सुरक्षा और सरलता के लिए, मैं यह मानने की सलाह देता हूं कि उनके पास फ्लैश-आधारित भंडारण जैसी ही व्यावहारिक अनिश्चितता है।
जब तक आपके पास कोई विशिष्ट सबूत न हो, जो आप स्पष्ट रूप से नहीं करते हैं। HDDs कताई के लिए मेरे पास तुलनात्मक आंकड़े नहीं हैं।
एक HDD खराब चेकसम के साथ एक अधूरे लिखित क्षेत्र को छोड़ सकता है, जो हमें बाद में एक अच्छी पढ़ने में विफलता देगा। मोटे तौर पर, HDDs की यह विफलता मोड पूरी तरह से अपेक्षित है; देशी लिनक्स फाइल सिस्टम को ध्यान में रखते हुए बनाया गया है। उनका लक्ष्य fsync()इस प्रकार की बिजली हानि दोष की स्थिति में अनुबंध को संरक्षित करना है। (हम वास्तव में SSDs पर इसकी गारंटी देखना चाहेंगे)।
हालाँकि मुझे यकीन नहीं है कि क्या लिनक्स फाइल सिस्टम सभी मामलों में इसे हासिल करता है, या यह संभव भी है।
इस प्रकार की गलती के बाद अगले बूट को एक फाइल सिस्टम मरम्मत की आवश्यकता हो सकती है। यह लिनक्स होने के नाते, यह संभव है कि फाइलसिस्टम की मरम्मत कुछ सवाल पूछेंगी जो आपको समझ में नहीं आते हैं, जहां आप केवल वाई को दबा सकते हैं और आशा करते हैं कि यह खुद को हल कर लेगा।
2.1 यदि आप नहीं जानते कि fsync () अनुबंध क्या है
Fsync () अनुबंध अच्छी खबर और बुरी खबर दोनों का एक स्रोत है। आपको पहले अच्छी खबर को समझना चाहिए।
अच्छी खबर: fsync()फ़ाइल डेटा लिखने के सही तरीके के रूप में अच्छी तरह से प्रलेखित है जैसे कि जब आप "सेव" को हिट करते हैं। और यह व्यापक रूप से समझा जाता है कि उदाहरण के लिए पाठ संपादकों को मौजूदा फ़ाइलों को अनिवार्य रूप से उपयोग करना चाहिए rename()। यह सुनिश्चित करने के लिए है कि आप हमेशा या तो पुरानी फ़ाइल रखते हैं, या नई फ़ाइल प्राप्त करते हैं (जो fsync()कि नाम बदलने से पहले एड की गई थी )। आप नई फ़ाइल के आधे लिखित संस्करण के साथ नहीं रहना चाहते हैं।
बुरी खबर: कई सालों से, सबसे लोकप्रिय लिनक्स फाइल सिस्टम पर fsync () कॉलिंग प्रभावी रूप से दसियों सेकंड के लिए लटकाए गए पूरे सिस्टम को प्रभावी ढंग से छोड़ सकती है। चूँकि अनुप्रयोग इस बारे में कुछ नहीं कर सकते हैं, इसलिए fsync () के बिना नाम बदलने () का उपयोग करना सामान्य था, जो इस फाइलसिस्टम पर अपेक्षाकृत विश्वसनीय प्रतीत होता था।
इसलिए, एप्लिकेशन मौजूद हैं जो fsync () का सही उपयोग नहीं करते हैं।
इस फाइलसिस्टम के अगले संस्करण में आमतौर पर fsync () हैंग से बचा जाता है - साथ ही साथ यह fsync () के सही उपयोग पर निर्भर होने लगा।
यह सब बहुत बुरा है। इस इतिहास को समझना संभवत: खारिज करने वाले स्वर और अभेद्य द्वारा मदद नहीं करता है जो कि कई परस्पर विरोधी कर्नेल डेवलपर्स द्वारा उपयोग किया गया था।
वर्तमान रिज़ॉल्यूशन यह है कि वर्तमान सबसे लोकप्रिय लिनक्स फाइल सिस्टम नाम बदलने का समर्थन करने के लिए चूक () fsync की आवश्यकता के बिना पैटर्न ()पिछले संस्करण के साथ "बग-फॉर-बग संगतता" को लागू करता है। इसे माउंट विकल्प के साथ अक्षम किया जा सकता है noauto_da_alloc।
यह पूर्ण सुरक्षा नहीं है। मूल रूप से यह नामांकित () समय पर लंबित IO को निकाल देता है, लेकिन यह नाम बदलने से पहले IO के पूरा होने की प्रतीक्षा नहीं करता है। हालांकि यह एक 60 सेकंड खतरे की खिड़की की तुलना में बहुत बेहतर है! यह भी देखें कि किसी मौजूदा फ़ाइल को नाम बदलने () के साथ बदलने के दौरान क्रैश-सुरक्षा के लिए किन फाइल सिस्टमों के लिए fsync () की आवश्यकता होती है?
कुछ कम लोकप्रिय फाइल सिस्टम सुरक्षा प्रदान नहीं करते हैं। XFS ऐसा करने से इनकार करता है। और यूबीआईएफएस ने इसे लागू नहीं किया है, जाहिरा तौर पर इसे स्वीकार किया जा सकता है लेकिन इसे संभव बनाने के लिए बहुत काम करने की आवश्यकता है। एक ही पृष्ठ बताता है कि यूबीआईएफएस में डेटा अखंडता के लिए कई अन्य "TODO" मुद्दे हैं, जिसमें बिजली की हानि भी शामिल है। UBIFS एक फाइलसिस्टम है जिसका उपयोग सीधे फ्लैश स्टोरेज पर किया जाता है। मुझे लगता है कि फ्लैश स्टोरेज के साथ UBIFS उल्लेखों में से कुछ कठिनाइयों SSD कीड़े के लिए प्रासंगिक हो सकता है।