पृष्ठभूमि

हमारे अपने डिज़ाइन की वेंडिंग मशीनें हैं। रास्पबेरी पाई के अंदर और एक अलग बोर्ड पर कुछ वायरिंग। एक सिक्का स्वीकर्ता, एक बिल स्वीकर्ता, एक बैंक टर्मिनल जुड़े हुए हैं... सब कुछ एक स्व-लिखित कार्यक्रम द्वारा नियंत्रित किया जाता है। संपूर्ण कार्य इतिहास एक फ्लैश ड्राइव (माइक्रोएसडी) पर एक लॉग में लिखा जाता है, जिसे फिर इंटरनेट के माध्यम से (यूएसबी मॉडेम का उपयोग करके) सर्वर पर प्रेषित किया जाता है, जहां इसे डेटाबेस में संग्रहीत किया जाता है। बिक्री की जानकारी 1सी में लोड की जाती है, निगरानी आदि के लिए एक सरल वेब इंटरफ़ेस भी है।

यानी, जर्नल महत्वपूर्ण है - लेखांकन (राजस्व, बिक्री, आदि), निगरानी (सभी प्रकार की विफलताओं और अन्य अप्रत्याशित परिस्थितियों) के लिए; कोई कह सकता है कि इस मशीन के बारे में हमारे पास यही सारी जानकारी है।

समस्या

फ्लैश ड्राइव स्वयं को बहुत अविश्वसनीय डिवाइस के रूप में प्रदर्शित करते हैं। वे गहरी नियमितता के साथ असफल होते हैं। इससे मशीन डाउनटाइम हो जाती है और (यदि किसी कारण से लॉग ऑनलाइन स्थानांतरित नहीं किया जा सका) तो डेटा हानि होती है।

फ्लैश ड्राइव का उपयोग करने का यह पहला अनुभव नहीं है, इससे पहले सौ से अधिक उपकरणों के साथ एक और परियोजना थी, जहां पत्रिका को यूएसबी फ्लैश ड्राइव पर संग्रहीत किया गया था, विश्वसनीयता के साथ समस्याएं भी थीं, कई बार विफल होने वालों की संख्या भी अधिक थी एक महीना दर्जनों में था। हमने अलग-अलग फ्लैश ड्राइव आज़माए, जिनमें एसएलसी मेमोरी वाले ब्रांडेड भी शामिल हैं, और कुछ मॉडल दूसरों की तुलना में अधिक विश्वसनीय हैं, लेकिन फ्लैश ड्राइव को बदलने से समस्या का मौलिक समाधान नहीं हुआ।

चेतावनी! लंबे समय तक पढ़ें! यदि आपकी रुचि "क्यों" में नहीं, केवल "कैसे" में है, तो आप सीधे जा सकते हैं धागे में लेख।

समाधान

पहली बात जो दिमाग में आती है वह है: माइक्रोएसडी को त्यागें, उदाहरण के लिए, एक एसएसडी स्थापित करें और उससे बूट करें। सैद्धांतिक रूप से संभव है, शायद, लेकिन अपेक्षाकृत महंगा है, और इतना विश्वसनीय नहीं है (एक यूएसबी-एसएटीए एडाप्टर जोड़ा गया है; बजट एसएसडी के लिए विफलता के आंकड़े भी उत्साहजनक नहीं हैं)।

USB HDD भी कोई विशेष आकर्षक समाधान नहीं दिखता।

इसलिए, हम इस विकल्प पर आए: माइक्रोएसडी से बूटिंग छोड़ें, लेकिन उन्हें केवल-पढ़ने के लिए मोड में उपयोग करें, और ऑपरेशन लॉग (और हार्डवेयर के किसी विशेष टुकड़े के लिए अद्वितीय अन्य जानकारी - सीरियल नंबर, सेंसर कैलिब्रेशन इत्यादि) को कहीं और संग्रहीत करें। .

रसभरी के लिए रीड-ओनली एफएस के विषय पर पहले ही अंदर और बाहर अध्ययन किया जा चुका है, मैं इस लेख में कार्यान्वयन विवरण पर ध्यान नहीं दूंगा। (लेकिन अगर रुचि हो तो शायद मैं इस विषय पर एक लघु लेख लिखूंगा). एकमात्र बिंदु जो मैं नोट करना चाहूंगा वह यह है कि व्यक्तिगत अनुभव और उन लोगों की समीक्षाओं से, जिन्होंने इसे पहले ही लागू कर दिया है, विश्वसनीयता में वृद्धि हुई है। हां, ब्रेकडाउन से पूरी तरह छुटकारा पाना असंभव है, लेकिन उनकी आवृत्ति को काफी कम करना काफी संभव है। और कार्ड एकीकृत होते जा रहे हैं, जिससे सेवा कर्मियों के लिए प्रतिस्थापन बहुत आसान हो गया है।

हार्डवेयर हिस्सा

मेमोरी प्रकार - NOR फ़्लैश की पसंद के बारे में कोई विशेष संदेह नहीं था।
तर्क:

सरल कनेक्शन (अक्सर एसपीआई बस, जिसका उपयोग करने का आपके पास पहले से ही अनुभव है, इसलिए कोई हार्डवेयर समस्या अपेक्षित नहीं है);
हास्यास्पद कीमत;
मानक ऑपरेटिंग प्रोटोकॉल (कार्यान्वयन पहले से ही लिनक्स कर्नेल में है, यदि आप चाहें, तो आप एक तृतीय-पक्ष प्रोटोकॉल ले सकते हैं, जो मौजूद भी है, या अपना खुद का भी लिख सकते हैं, सौभाग्य से सब कुछ सरल है);
विश्वसनीयता और संसाधन:
एक सामान्य डेटाशीट से: डेटा 20 वर्षों तक संग्रहीत किया जाता है, प्रत्येक ब्लॉक के लिए 100000 मिटाने के चक्र;
तीसरे पक्ष के स्रोतों से: बेहद कम बीईआर, त्रुटि सुधार कोड की कोई आवश्यकता नहीं बताता है (कुछ कार्य NOR के लिए ECC पर विचार करते हैं, लेकिन आम तौर पर उनका मतलब अभी भी MLC NOR होता है; ऐसा भी होता है).

आइए मात्रा और संसाधन की आवश्यकताओं का अनुमान लगाएं।

मैं चाहूंगा कि डेटा को कई दिनों तक सहेजे जाने की गारंटी दी जाए। यह आवश्यक है ताकि किसी भी संचार समस्या की स्थिति में बिक्री इतिहास नष्ट न हो जाए। इस दौरान हम 5 दिनों पर फोकस करेंगे (सप्ताहांत और छुट्टियों को ध्यान में रखते हुए भी) समस्या का समाधान हो सकता है.

वर्तमान में हम प्रति दिन लगभग 100 केबी लॉग (3-4 हजार प्रविष्टियाँ) एकत्र करते हैं, लेकिन धीरे-धीरे यह आंकड़ा बढ़ रहा है - विवरण बढ़ रहा है, नई घटनाएं जोड़ी जा रही हैं। साथ ही, कभी-कभी विस्फोट भी होते हैं (उदाहरण के लिए, कुछ सेंसर झूठी सकारात्मकता के साथ स्पैमिंग शुरू कर देते हैं)। हम 10 हजार रिकॉर्ड के लिए 100 बाइट्स प्रत्येक - प्रति दिन मेगाबाइट की गणना करेंगे।

कुल मिलाकर, 5एमबी स्वच्छ (अच्छी तरह से संपीड़ित) डेटा निकलता है। उनके लिए और अधिक (मोटा अनुमान) 1एमबी सेवा डेटा।

अर्थात्, यदि हम कम्प्रेशन का उपयोग नहीं करते हैं तो हमें 8MB चिप की आवश्यकता है, या यदि हम इसका उपयोग करते हैं तो 4MB की। इस प्रकार की मेमोरी के लिए काफी यथार्थवादी संख्याएँ।

संसाधन के लिए: यदि हम योजना बनाते हैं कि पूरी मेमोरी को हर 5 दिनों में एक बार से अधिक नहीं लिखा जाएगा, तो 10 वर्षों की सेवा में हमें एक हजार से भी कम पुनर्लेखन चक्र मिलते हैं।
मैं आपको याद दिला दूं कि निर्माता एक लाख का वादा करता है।

NOR बनाम NAND के बारे में थोड़ा

आज, निश्चित रूप से, NAND मेमोरी बहुत अधिक लोकप्रिय है, लेकिन मैं इसे इस परियोजना के लिए उपयोग नहीं करूंगा: NAND, NOR के विपरीत, आवश्यक रूप से त्रुटि सुधार कोड, खराब ब्लॉकों की एक तालिका, आदि के उपयोग की आवश्यकता होती है, और इसके पैरों की भी NAND चिप्स आमतौर पर बहुत अधिक होते हैं।

NOR के नुकसानों में शामिल हैं:

छोटी मात्रा (और, तदनुसार, प्रति मेगाबाइट उच्च कीमत);
कम संचार गति (मुख्यतः इस तथ्य के कारण कि एक सीरियल इंटरफ़ेस का उपयोग किया जाता है, आमतौर पर SPI या I2C);
धीमी गति से मिटाना (ब्लॉक आकार के आधार पर, इसमें एक सेकंड से लेकर कई सेकंड तक का समय लगता है)।

ऐसा लगता है कि हमारे लिए कुछ भी महत्वपूर्ण नहीं है, इसलिए हम जारी रखते हैं।

यदि विवरण दिलचस्प हैं, तो माइक्रोक्रिकिट का चयन किया गया है at25df321a (हालांकि, यह महत्वहीन है, बाजार में बहुत सारे एनालॉग हैं जो पिनआउट और कमांड सिस्टम में संगत हैं; भले ही हम एक अलग निर्माता और/या एक अलग आकार से माइक्रोक्रिकिट स्थापित करना चाहते हैं, सब कुछ बदले बिना काम करेगा कोड).

मैं लिनक्स कर्नेल में निर्मित ड्राइवर का उपयोग करता हूं; रास्पबेरी पर, डिवाइस ट्री ओवरले समर्थन के लिए धन्यवाद, सब कुछ बहुत सरल है - आपको संकलित ओवरले को /boot/overlays में डालना होगा और /boot/config.txt को थोड़ा संशोधित करना होगा।

उदाहरण डीटीएस फ़ाइल

ईमानदारी से कहूँ तो, मुझे यकीन नहीं है कि यह त्रुटियों के बिना लिखा गया है, लेकिन यह काम करता है।

/*
 * Device tree overlay for at25 at spi0.1
 */

/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2835", "brcm,bcm2836", "brcm,bcm2708", "brcm,bcm2709"; 

    /* disable spi-dev for spi0.1 */
    fragment@0 {
        target = <&spi0>;
        __overlay__ {
            status = "okay";
            spidev@1{
                status = "disabled";
            };
        };
    };

    /* the spi config of the at25 */
    fragment@1 {
        target = <&spi0>;
        __overlay__ {
            #address-cells = <1>;
            #size-cells = <0>;
            flash: m25p80@1 {
                    compatible = "atmel,at25df321a";
                    reg = <1>;
                    spi-max-frequency = <50000000>;

                    /* default to false:
                    m25p,fast-read ;
                    */
            };
        };
    };

    __overrides__ {
        spimaxfrequency = <&flash>,"spi-max-frequency:0";
        fastread = <&flash>,"m25p,fast-read?";
    };
};

और config.txt में एक और पंक्ति

dtoverlay=at25:spimaxfrequency=50000000

मैं चिप को रास्पबेरी पाई से जोड़ने का विवरण छोड़ दूंगा। एक ओर, मैं इलेक्ट्रॉनिक्स का विशेषज्ञ नहीं हूं, दूसरी ओर, यहां सब कुछ मेरे लिए भी सामान्य है: माइक्रोक्रिकिट में केवल 8 पैर हैं, जिनमें से हमें ग्राउंड, पावर, एसपीआई (सीएस, एसआई, एसओ, एससीके) की आवश्यकता है ); स्तर रास्पबेरी पाई के समान हैं, किसी अतिरिक्त वायरिंग की आवश्यकता नहीं है - बस संकेतित 6 पिन कनेक्ट करें।

समस्या का निरूपण

हमेशा की तरह, समस्या कथन कई पुनरावृत्तियों से गुजरता है, और मुझे ऐसा लगता है कि यह अगले का समय है। तो आइए रुकें, जो पहले ही लिखा जा चुका है उसे एक साथ रखें, और उन विवरणों को स्पष्ट करें जो छाया में रह गए हैं।

इसलिए, हमने निर्णय लिया है कि लॉग को SPI NOR फ़्लैश में संग्रहीत किया जाएगा।

जो लोग नहीं जानते उनके लिए NOR फ़्लैश क्या है?

यह गैर-वाष्पशील मेमोरी है जिसके साथ आप तीन ऑपरेशन कर सकते हैं:

अध्ययन:
सबसे आम रीडिंग: हम पता प्रसारित करते हैं और जितनी जरूरत हो उतने बाइट्स पढ़ते हैं;
रिकॉर्ड:
NOR फ़्लैश पर लिखना एक नियमित जैसा दिखता है, लेकिन इसकी एक ख़ासियत है: आप केवल 1 से 0 बदल सकते हैं, लेकिन इसके विपरीत नहीं। उदाहरण के लिए, यदि हमारे पास मेमोरी सेल में 0x55 है, तो उसमें 0x0f लिखने के बाद, 0x05 पहले से ही वहां संग्रहीत हो जाएगा (नीचे तालिका देखें);
मिटाएं:
निःसंदेह, हमें विपरीत ऑपरेशन करने में सक्षम होने की आवश्यकता है - 0 को 1 में बदलें, मिटाना ऑपरेशन बिल्कुल इसी के लिए है। पहले दो के विपरीत, यह बाइट्स के साथ नहीं, बल्कि ब्लॉक के साथ संचालित होता है (चयनित चिप में न्यूनतम मिटा ब्लॉक 4kb है)। मिटाना पूरे ब्लॉक को नष्ट कर देता है और 0 को 1 में बदलने का एकमात्र तरीका है। इसलिए, फ्लैश मेमोरी के साथ काम करते समय, आपको अक्सर डेटा संरचनाओं को मिटाए गए ब्लॉक सीमा पर संरेखित करना पड़ता है।
NOR फ़्लैश में रिकॉर्डिंग:

बाइनरी डेटा

यह था
01010101

रिकॉर्डेड
00001111

यह बन गया
00000101

लॉग स्वयं परिवर्तनीय लंबाई के रिकॉर्ड के अनुक्रम का प्रतिनिधित्व करता है। एक रिकॉर्ड की सामान्य लंबाई लगभग 30 बाइट्स होती है (हालाँकि कभी-कभी ऐसे रिकॉर्ड होते हैं जिनकी लंबाई कई किलोबाइट होती है)। इस मामले में, हम उनके साथ केवल बाइट्स के एक सेट के रूप में काम करते हैं, लेकिन, यदि आप रुचि रखते हैं, तो सीबीओआर का उपयोग रिकॉर्ड के अंदर किया जाता है

लॉग के अलावा, हमें कुछ "सेटिंग" जानकारी संग्रहीत करने की आवश्यकता है, दोनों अद्यतन और नहीं: एक निश्चित डिवाइस आईडी, सेंसर अंशांकन, एक "डिवाइस अस्थायी रूप से अक्षम है" ध्वज, आदि।
यह जानकारी कुंजी-मूल्य रिकॉर्ड का एक सेट है, जिसे सीबीओआर में भी संग्रहीत किया जाता है। हमारे पास यह जानकारी बहुत अधिक नहीं है (अधिकतम कुछ किलोबाइट), और इसे कभी-कभार ही अपडेट किया जाता है।
निम्नलिखित में हम इसे संदर्भ कहेंगे।

यदि हमें याद है कि यह लेख कहाँ से शुरू हुआ था, तो विश्वसनीय डेटा भंडारण सुनिश्चित करना और, यदि संभव हो तो, हार्डवेयर विफलता/डेटा भ्रष्टाचार की स्थिति में भी निरंतर संचालन सुनिश्चित करना बहुत महत्वपूर्ण है।

समस्याओं के किन स्रोतों पर विचार किया जा सकता है?

लिखने/मिटाने की कार्रवाई के दौरान बिजली बंद। यह "क्राउबार के विरुद्ध कोई चाल नहीं है" की श्रेणी से है।
इससे जानकारी विचार-विमर्श स्टैकएक्सचेंज पर: जब फ्लैश के साथ काम करते समय बिजली बंद हो जाती है, तो मिटाएं (1 पर सेट करें) और लिखें (0 पर सेट करें) दोनों अपरिभाषित व्यवहार की ओर ले जाते हैं: डेटा लिखा जा सकता है, आंशिक रूप से लिखा जा सकता है (मान लीजिए, हमने 10 बाइट्स/80 बिट्स स्थानांतरित किए हैं) , लेकिन अभी तक केवल 45 बिट्स ही नहीं लिखे जा सकते हैं), यह भी संभव है कि कुछ बिट्स "मध्यवर्ती" स्थिति में होंगे (पढ़ने से 0 और 1 दोनों उत्पन्न हो सकते हैं);
फ़्लैश मेमोरी में ही त्रुटियाँ।
बीईआर, हालांकि बहुत कम है, शून्य के बराबर नहीं हो सकता;
बस त्रुटियाँ
एसपीआई के माध्यम से प्रेषित डेटा किसी भी तरह से सुरक्षित नहीं है; एकल बिट त्रुटियां और सिंक्रोनाइज़ेशन त्रुटियां दोनों हो सकती हैं - बिट्स का नुकसान या सम्मिलन (जिससे बड़े पैमाने पर डेटा विरूपण होता है);
अन्य त्रुटियाँ/गड़बड़ियाँ
कोड में त्रुटियाँ, रास्पबेरी गड़बड़ियाँ, विदेशी हस्तक्षेप...

मैंने आवश्यकताएँ तैयार की हैं, जिनकी पूर्ति, मेरी राय में, विश्वसनीयता सुनिश्चित करने के लिए आवश्यक है:

रिकॉर्ड को तुरंत फ्लैश मेमोरी में जाना चाहिए, विलंबित लेखन पर विचार नहीं किया जाता है; - यदि कोई त्रुटि होती है, तो इसे जल्द से जल्द पता लगाया जाना चाहिए और संसाधित किया जाना चाहिए; - यदि संभव हो तो सिस्टम को त्रुटियों से उबरना चाहिए।
(जीवन से एक उदाहरण "यह कैसे नहीं होना चाहिए", जो मुझे लगता है कि हर किसी ने सामना किया है: आपातकालीन रिबूट के बाद, फ़ाइल सिस्टम "टूट गया" है और ऑपरेटिंग सिस्टम बूट नहीं होता है)

विचार, दृष्टिकोण, चिंतन

जब मैंने इस समस्या के बारे में सोचना शुरू किया, तो मेरे दिमाग में बहुत सारे विचार कौंध गए, उदाहरण के लिए:

डेटा संपीड़न का उपयोग करें;
चतुर डेटा संरचनाओं का उपयोग करें, उदाहरण के लिए, रिकॉर्ड हेडर को रिकॉर्ड से अलग संग्रहीत करना, ताकि यदि किसी रिकॉर्ड में कोई त्रुटि हो, तो आप बिना किसी समस्या के बाकी को पढ़ सकें;
बिजली बंद होने पर रिकॉर्डिंग के पूरा होने को नियंत्रित करने के लिए बिट फ़ील्ड का उपयोग करें;
हर चीज़ के लिए चेकसम स्टोर करें;
किसी प्रकार की शोर-प्रतिरोधी कोडिंग का उपयोग करें।

इनमें से कुछ विचारों का उपयोग किया गया, जबकि अन्य को त्यागने का निर्णय लिया गया। आइए क्रम से चलें.

आधार - सामग्री संकोचन

जो घटनाएँ हम जर्नल में दर्ज करते हैं वे स्वयं काफी समान और दोहराई जाने योग्य हैं ("5 रूबल का सिक्का फेंका", "चेंज देने के लिए बटन दबाया", ...)। इसलिए, संपीड़न काफी प्रभावी होना चाहिए.

संपीड़न ओवरहेड नगण्य है (हमारा प्रोसेसर काफी शक्तिशाली है, यहां तक कि पहले पीआई में 700 मेगाहर्ट्ज की आवृत्ति के साथ एक कोर था, वर्तमान मॉडल में गीगाहर्ट्ज़ से अधिक की आवृत्ति के साथ कई कोर हैं), भंडारण के साथ विनिमय दर कम है (कई) मेगाबाइट प्रति सेकंड), रिकॉर्ड का आकार छोटा है। सामान्य तौर पर, यदि संपीड़न का प्रदर्शन पर प्रभाव पड़ता है, तो यह केवल सकारात्मक होगा। (बिलकुल आलोचनात्मक नहीं, बस बता रहा हूं). साथ ही, हमारे पास वास्तविक एम्बेडेड नहीं है, लेकिन नियमित लिनक्स है - इसलिए कार्यान्वयन के लिए अधिक प्रयास की आवश्यकता नहीं होनी चाहिए (यह केवल लाइब्रेरी को लिंक करने और उससे कई कार्यों का उपयोग करने के लिए पर्याप्त है)।

लॉग का एक टुकड़ा एक कार्यशील डिवाइस (1.7 एमबी, 70 हजार प्रविष्टियाँ) से लिया गया था और पहले कंप्यूटर पर उपलब्ध gzip, lz4, lzop, bzip2, xz, zstd का उपयोग करके संपीड़ितता के लिए जाँच की गई थी।

gzip, xz, zstd ने समान परिणाम दिखाए (40Kb)।
मुझे आश्चर्य हुआ कि फैशनेबल xz ने खुद को यहां gzip या zstd के स्तर पर दिखाया;
डिफ़ॉल्ट सेटिंग्स के साथ lzip ने थोड़े खराब परिणाम दिए;
lz4 और lzop ने बहुत अच्छे परिणाम नहीं दिखाए (150Kb);
bzip2 ने आश्चर्यजनक रूप से अच्छा परिणाम (18Kb) दिखाया।

तो, डेटा बहुत अच्छी तरह से संपीड़ित है।
तो (यदि हमें घातक खामियाँ नहीं मिलीं) तो संपीड़न होगा! सिर्फ इसलिए कि अधिक डेटा एक ही फ्लैश ड्राइव पर फिट हो सकता है।

आइए नुकसान के बारे में सोचें.

पहली समस्या: हम पहले ही इस बात पर सहमत हो चुके हैं कि प्रत्येक रिकॉर्ड को तुरंत फ़्लैश किया जाना चाहिए। आमतौर पर, संग्रहकर्ता इनपुट स्ट्रीम से डेटा एकत्र करता है जब तक कि वह यह निर्णय नहीं ले लेता कि यह सप्ताहांत पर लिखने का समय है। हमें तुरंत डेटा का एक संपीड़ित ब्लॉक प्राप्त करने और इसे गैर-वाष्पशील मेमोरी में संग्रहीत करने की आवश्यकता है।

मैं तीन तरीके देखता हूं:

ऊपर चर्चा किए गए एल्गोरिदम के बजाय शब्दकोश संपीड़न का उपयोग करके प्रत्येक रिकॉर्ड को संपीड़ित करें।
यह पूरी तरह से काम करने वाला विकल्प है, लेकिन मुझे यह पसंद नहीं है। संपीड़न के अधिक या कम सभ्य स्तर को सुनिश्चित करने के लिए, शब्दकोश को विशिष्ट डेटा के लिए "अनुरूप" किया जाना चाहिए; किसी भी परिवर्तन से संपीड़न स्तर में भारी गिरावट आएगी। हाँ, समस्या को शब्दकोश का एक नया संस्करण बनाकर हल किया जा सकता है, लेकिन यह एक सिरदर्द है - हमें शब्दकोश के सभी संस्करणों को संग्रहीत करने की आवश्यकता होगी; प्रत्येक प्रविष्टि में हमें यह बताना होगा कि इसे शब्दकोश के किस संस्करण से संपीड़ित किया गया था...
"शास्त्रीय" एल्गोरिदम का उपयोग करके प्रत्येक रिकॉर्ड को संपीड़ित करें, लेकिन दूसरों से स्वतंत्र रूप से।
विचाराधीन संपीड़न एल्गोरिदम इस आकार (दसियों बाइट्स) के रिकॉर्ड के साथ काम करने के लिए डिज़ाइन नहीं किए गए हैं, संपीड़न अनुपात स्पष्ट रूप से 1 से कम होगा (अर्थात, संपीड़ित करने के बजाय डेटा की मात्रा बढ़ाना);
प्रत्येक रिकॉर्डिंग के बाद फ्लश करें।
कई संपीड़न पुस्तकालयों में FLUSH के लिए समर्थन है। यह एक कमांड (या संपीड़न प्रक्रिया का एक पैरामीटर) है, जिसे प्राप्त करने पर संग्रहकर्ता एक संपीड़ित स्ट्रीम बनाता है ताकि इसे पुनर्स्थापित करने के लिए उपयोग किया जा सके सब असम्पीडित डेटा जो पहले ही प्राप्त हो चुका है। ऐसा एनालॉग sync फ़ाइल सिस्टम में या commit एसक्यूएल में.
महत्वपूर्ण बात यह है कि बाद के संपीड़न ऑपरेशन संचित शब्दकोश का उपयोग करने में सक्षम होंगे और संपीड़न अनुपात पिछले संस्करण जितना प्रभावित नहीं होगा।

मुझे लगता है कि यह स्पष्ट है कि मैंने तीसरा विकल्प चुना, आइए इसे और अधिक विस्तार से देखें।

मिला महान लेख zlib में FLUSH के बारे में।

मैंने लेख के आधार पर घुटने का परीक्षण किया, एक वास्तविक डिवाइस से 70 हजार लॉग प्रविष्टियाँ लीं, जिसका पृष्ठ आकार 60Kb था (हम बाद में पृष्ठ आकार पर वापस आएंगे) प्राप्त हुआ:

कच्चा डेटा
संपीड़न gzip -9 (कोई फ्लश नहीं)
Z_PARTIAL_FLUSH के साथ zlib
Z_SYNC_FLUSH के साथ zlib

वॉल्यूम, केबी
1692
40
352
604

पहली नज़र में, FLUSH द्वारा योगदान की गई कीमत अत्यधिक अधिक है, लेकिन वास्तव में हमारे पास बहुत कम विकल्प हैं - या तो बिल्कुल भी संपीड़ित न करें, या FLUSH के साथ संपीड़ित (और बहुत प्रभावी ढंग से) करें। हमें यह नहीं भूलना चाहिए कि हमारे पास 70 हजार रिकॉर्ड हैं, Z_PARTIAL_FLUSH द्वारा शुरू की गई अतिरेक प्रति रिकॉर्ड केवल 4-5 बाइट्स है। और संपीड़न अनुपात लगभग 5:1 हो गया, जो एक उत्कृष्ट परिणाम से कहीं अधिक है।

यह आश्चर्य की बात हो सकती है, लेकिन Z_SYNC_FLUSH वास्तव में FLUSH करने का एक अधिक कुशल तरीका है

Z_SYNC_FLUSH का उपयोग करते समय, प्रत्येक प्रविष्टि के अंतिम 4 बाइट्स हमेशा 0x00, 0x00, 0xff, 0xff होंगे। और यदि हम उन्हें जानते हैं, तो हमें उन्हें संग्रहीत करने की आवश्यकता नहीं है, इसलिए अंतिम आकार केवल 324Kb है।

जिस आलेख से मैंने लिंक किया है उसमें एक स्पष्टीकरण है:

खाली सामग्री वाला एक नया प्रकार 0 ब्लॉक जोड़ा गया है।

खाली सामग्री वाले टाइप 0 ब्लॉक में निम्न शामिल हैं:

तीन-बिट ब्लॉक हेडर;

बाइट संरेखण प्राप्त करने के लिए 0 से 7 बिट्स शून्य के बराबर;

चार-बाइट अनुक्रम 00 00 एफएफ एफएफ।

जैसा कि आप आसानी से देख सकते हैं, इन 4 बाइट्स से पहले अंतिम ब्लॉक में 3 से 10 शून्य बिट्स हैं। हालाँकि, अभ्यास से पता चला है कि वास्तव में कम से कम 10 शून्य बिट हैं।

यह पता चला है कि डेटा के ऐसे छोटे ब्लॉक आमतौर पर (हमेशा?) टाइप 1 (फिक्स्ड ब्लॉक) के ब्लॉक का उपयोग करके एन्कोड किए जाते हैं, जो आवश्यक रूप से 7 शून्य बिट्स के साथ समाप्त होता है, जिससे कुल 10-17 गारंटीकृत शून्य बिट्स मिलते हैं (और बाकी होंगे) लगभग 50% की संभावना के साथ शून्य हो)।

तो, परीक्षण डेटा पर, 100% मामलों में 0x00, 0x00, 0xff, 0xff से पहले एक शून्य बाइट है, और एक तिहाई से अधिक मामलों में दो शून्य बाइट हैं (शायद तथ्य यह है कि मैं बाइनरी सीबीओआर का उपयोग करता हूं, और टेक्स्ट JSON का उपयोग करते समय, टाइप 2 के ब्लॉक - डायनेमिक ब्लॉक क्रमशः अधिक सामान्य होंगे, 0x00, 0x00, 0xff, 0xff से पहले अतिरिक्त शून्य बाइट्स के बिना ब्लॉक का सामना किया जाएगा).

कुल मिलाकर, उपलब्ध परीक्षण डेटा का उपयोग करके, 250Kb से कम संपीड़ित डेटा को फिट करना संभव है।

आप बिट बाजीगरी करके थोड़ी अधिक बचत कर सकते हैं: अभी के लिए हम ब्लॉक के अंत में कुछ शून्य बिट्स की उपस्थिति को नजरअंदाज करते हैं, ब्लॉक की शुरुआत में कुछ बिट्स भी नहीं बदलते हैं...
लेकिन फिर मैंने रुकने का दृढ़ इच्छाशक्ति वाला निर्णय लिया, अन्यथा इस गति से मैं अपना स्वयं का संग्रहकर्ता विकसित कर सकता था।

कुल मिलाकर, मेरे परीक्षण डेटा से मुझे प्रति लेखन 3-4 बाइट्स प्राप्त हुए, संपीड़न अनुपात 6:1 से अधिक निकला। मैं ईमानदार रहूँगा: मुझे ऐसे परिणाम की उम्मीद नहीं थी; मेरी राय में, 2:1 से बेहतर कुछ भी पहले से ही एक परिणाम है जो संपीड़न के उपयोग को उचित ठहराता है।

सब कुछ ठीक है, लेकिन ज़्लिब (डिफ्लेट) अभी भी एक पुरातन, सुयोग्य और थोड़ा पुराने जमाने का संपीड़न एल्गोरिथ्म है। केवल यह तथ्य कि असम्पीडित डेटा स्ट्रीम के अंतिम 32Kb को एक शब्दकोश के रूप में उपयोग किया जाता है, आज अजीब लगता है (अर्थात, यदि कुछ डेटा ब्लॉक 40Kb पहले इनपुट स्ट्रीम के समान है, तो इसे फिर से संग्रहीत किया जाना शुरू हो जाएगा, और पिछली घटना का उल्लेख नहीं करेगा)। फैशनेबल आधुनिक संग्रहकर्ताओं में, शब्दकोश का आकार अक्सर किलोबाइट्स के बजाय मेगाबाइट्स में मापा जाता है।

इसलिए हम अभिलेखागारों का अपना लघु-अध्ययन जारी रखते हैं।

इसके बाद हमने bzip2 का परीक्षण किया (याद रखें, FLUSH के बिना इसने लगभग 100:1 का शानदार संपीड़न अनुपात दिखाया)। दुर्भाग्य से, इसने FLUSH के साथ बहुत खराब प्रदर्शन किया; संपीड़ित डेटा का आकार असम्पीडित डेटा से बड़ा निकला।

असफलता के कारणों के बारे में मेरी धारणाएँ

Libbz2 केवल एक फ्लश विकल्प प्रदान करता है, जो शब्दकोश को साफ़ करता प्रतीत होता है (zlib में Z_FULL_FLUSH के अनुरूप); इसके बाद किसी भी प्रभावी संपीड़न की कोई बात नहीं है।

और परीक्षण किया जाने वाला आखिरी परीक्षण zstd था। मापदंडों के आधार पर, यह या तो gzip के स्तर पर संपीड़ित होता है, लेकिन बहुत तेजी से, या gzip से बेहतर होता है।

अफ़सोस, FLUSH के साथ इसने बहुत अच्छा प्रदर्शन नहीं किया: संपीड़ित डेटा का आकार लगभग 700Kb था।

Я एक प्रश्न पूछा प्रोजेक्ट के जीथब पेज पर, मुझे उत्तर मिला कि आपको संपीड़ित डेटा के प्रत्येक ब्लॉक के लिए सेवा डेटा के 10 बाइट्स पर भरोसा करना चाहिए, जो प्राप्त परिणामों के करीब है; डिफ्लेट को पकड़ने का कोई तरीका नहीं है।

मैंने अभिलेखागार के साथ अपने प्रयोगों में इस बिंदु पर रुकने का फैसला किया (मैं आपको याद दिला दूं कि xz, lzip, lzo, lz4 ने FLUSH के बिना परीक्षण चरण में भी खुद को नहीं दिखाया, और मैंने अधिक विदेशी संपीड़न एल्गोरिदम पर विचार नहीं किया)।

आइए संग्रहण समस्याओं पर वापस लौटें।

दूसरी (जैसा कि वे क्रम में कहते हैं, मूल्य में नहीं) समस्या यह है कि संपीड़ित डेटा एक एकल स्ट्रीम है, जिसमें लगातार पिछले अनुभागों के संदर्भ होते हैं। इस प्रकार, यदि संपीड़ित डेटा का एक खंड क्षतिग्रस्त हो जाता है, तो हम न केवल असम्पीडित डेटा के संबंधित ब्लॉक को खो देते हैं, बल्कि उसके बाद के सभी ब्लॉक को भी खो देते हैं।

इस समस्या को हल करने का एक तरीका है:

समस्या को उत्पन्न होने से रोकें - संपीड़ित डेटा में अतिरेक जोड़ें, जो आपको त्रुटियों की पहचान करने और उन्हें ठीक करने की अनुमति देगा; हम इस बारे में बाद में बात करेंगे;
यदि कोई समस्या होती है तो परिणाम कम से कम करें
हम पहले ही कह चुके हैं कि आप प्रत्येक डेटा ब्लॉक को स्वतंत्र रूप से संपीड़ित कर सकते हैं, और समस्या अपने आप गायब हो जाएगी (एक ब्लॉक के डेटा को नुकसान होने से केवल इस ब्लॉक के डेटा की हानि होगी)। हालाँकि, यह एक चरम मामला है जिसमें डेटा संपीड़न अप्रभावी होगा। विपरीत चरम: हमारी चिप के सभी 4एमबी को एक एकल संग्रह के रूप में उपयोग करें, जो हमें उत्कृष्ट संपीड़न देगा, लेकिन डेटा भ्रष्टाचार के मामले में विनाशकारी परिणाम देगा।
हां, विश्वसनीयता के मामले में समझौता जरूरी है। लेकिन हमें याद रखना चाहिए कि हम बेहद कम बीईआर और 20 साल की घोषित डेटा भंडारण अवधि के साथ गैर-वाष्पशील मेमोरी के लिए एक डेटा भंडारण प्रारूप विकसित कर रहे हैं।

प्रयोगों के दौरान, मैंने पाया कि संपीड़न स्तर में कम या ज्यादा ध्यान देने योग्य हानि 10 केबी से कम आकार के संपीड़ित डेटा के ब्लॉक पर शुरू होती है।
यह पहले उल्लेख किया गया था कि उपयोग की गई मेमोरी पृष्ठांकित है; मुझे कोई कारण नहीं दिखता कि "एक पृष्ठ - संपीड़ित डेटा का एक ब्लॉक" पत्राचार का उपयोग क्यों नहीं किया जाना चाहिए।

अर्थात्, न्यूनतम उचित पृष्ठ आकार 16Kb है (सेवा जानकारी के लिए आरक्षित के साथ)। हालाँकि, इतना छोटा पृष्ठ आकार अधिकतम रिकॉर्ड आकार पर महत्वपूर्ण प्रतिबंध लगाता है।

हालाँकि मुझे अभी तक संपीड़ित रूप में कुछ किलोबाइट से बड़े रिकॉर्ड की उम्मीद नहीं है, मैंने 32Kb पृष्ठों (प्रति चिप कुल 128 पृष्ठों के लिए) का उपयोग करने का निर्णय लिया है।

सारांश:

हम zlib (डिफ्लेट) का उपयोग करके संपीड़ित डेटा संग्रहीत करते हैं;
प्रत्येक प्रविष्टि के लिए हम Z_SYNC_FLUSH सेट करते हैं;
प्रत्येक संपीड़ित रिकॉर्ड के लिए, हम अनुवर्ती बाइट्स को ट्रिम करते हैं (जैसे 0x00, 0x00, 0xff, 0xff); हेडर में हम दर्शाते हैं कि हमने कितने बाइट्स काटे;
हम डेटा को 32Kb पृष्ठों में संग्रहीत करते हैं; पृष्ठ के अंदर संपीड़ित डेटा की एक एकल धारा है; प्रत्येक पृष्ठ पर हम फिर से संपीड़न शुरू करते हैं।

और, संपीड़न के साथ समाप्त करने से पहले, मैं आपका ध्यान इस तथ्य पर आकर्षित करना चाहूंगा कि हमारे पास प्रति रिकॉर्ड संपीड़ित डेटा के केवल कुछ बाइट्स हैं, इसलिए यह बेहद महत्वपूर्ण है कि सेवा की जानकारी को न बढ़ाएं, यहां प्रत्येक बाइट मायने रखता है।

डेटा हेडर संग्रहीत करना

चूंकि हमारे पास परिवर्तनीय लंबाई के रिकॉर्ड हैं, इसलिए हमें किसी तरह रिकॉर्ड की स्थिति/सीमाएं निर्धारित करने की आवश्यकता है।

मैं तीन दृष्टिकोण जानता हूं:

सभी रिकॉर्ड एक सतत स्ट्रीम में संग्रहीत होते हैं, पहले एक रिकॉर्ड हेडर होता है जिसमें लंबाई होती है, और फिर रिकॉर्ड होता है।
इस अवतार में, हेडर और डेटा दोनों परिवर्तनशील लंबाई के हो सकते हैं।
मूलतः, हमें एक एकल लिंक्ड सूची मिलती है जिसका उपयोग हर समय किया जाता है;
हेडर और रिकॉर्ड स्वयं अलग-अलग स्ट्रीम में संग्रहीत होते हैं।
स्थिर लंबाई के हेडर का उपयोग करके, हम यह सुनिश्चित करते हैं कि एक हेडर की क्षति दूसरे को प्रभावित न करे।
एक समान दृष्टिकोण का उपयोग किया जाता है, उदाहरण के लिए, कई फ़ाइल सिस्टम में;
रिकॉर्ड एक सतत स्ट्रीम में संग्रहीत होते हैं, रिकॉर्ड सीमा एक निश्चित मार्कर (वर्णों का एक वर्ण/अनुक्रम जो डेटा ब्लॉक के भीतर निषिद्ध है) द्वारा निर्धारित की जाती है। यदि रिकॉर्ड के अंदर कोई मार्कर है, तो हम इसे कुछ अनुक्रम से बदल देते हैं (इससे बच जाते हैं)।
उदाहरण के लिए, पीपीपी प्रोटोकॉल में एक समान दृष्टिकोण का उपयोग किया जाता है।

मैं वर्णन करूंगा.

विकल्प 1:

यहां सब कुछ बहुत सरल है: रिकॉर्ड की लंबाई जानने के बाद, हम अगले हेडर के पते की गणना कर सकते हैं। इसलिए हम शीर्षकों के माध्यम से तब तक आगे बढ़ते हैं जब तक हमें 0xff (मुक्त क्षेत्र) से भरा क्षेत्र या पृष्ठ का अंत नहीं मिल जाता।

विकल्प 2:

परिवर्तनीय रिकॉर्ड लंबाई के कारण, हम पहले से नहीं कह सकते कि हमें प्रति पृष्ठ कितने रिकॉर्ड (और इसलिए हेडर) की आवश्यकता होगी। आप हेडर और डेटा को अलग-अलग पेजों पर फैला सकते हैं, लेकिन मैं एक अलग दृष्टिकोण पसंद करता हूं: हम हेडर और डेटा दोनों को एक पेज पर रखते हैं, लेकिन हेडर (स्थिर आकार के) पेज की शुरुआत से आते हैं, और डेटा (परिवर्तनीय लंबाई का) अंत से आता है। जैसे ही वे "मिलते हैं" (नई प्रविष्टि के लिए पर्याप्त खाली जगह नहीं है), हम इस पृष्ठ को पूर्ण मानते हैं।

विकल्प 3:

हेडर में डेटा के स्थान के बारे में लंबाई या अन्य जानकारी संग्रहीत करने की कोई आवश्यकता नहीं है; रिकॉर्ड की सीमाओं को इंगित करने वाले मार्कर पर्याप्त हैं। हालाँकि, लिखते/पढ़ते समय डेटा को संसाधित करना पड़ता है।
मैं एक मार्कर के रूप में 0xff का उपयोग करूंगा (जो मिटाए जाने के बाद पृष्ठ को भरता है), इसलिए मुक्त क्षेत्र को निश्चित रूप से डेटा के रूप में नहीं माना जाएगा।

तुलना तालिका:

देखिये 1
देखिये 2
देखिये 3

त्रुटि सहनशीलता
-
+
+

घनत्व
+
-
+

कार्यान्वयन जटिलता
*
**
**

विकल्प 1 में एक घातक दोष है: यदि कोई भी हेडर क्षतिग्रस्त हो जाता है, तो उसके बाद की पूरी श्रृंखला नष्ट हो जाती है। शेष विकल्प आपको भारी क्षति की स्थिति में भी कुछ डेटा पुनर्प्राप्त करने की अनुमति देते हैं।
लेकिन यहां यह याद रखना उचित है कि हमने डेटा को संपीड़ित रूप में संग्रहीत करने का निर्णय लिया है, और इसलिए हम "टूटे हुए" रिकॉर्ड के बाद पृष्ठ पर सभी डेटा खो देते हैं, इसलिए भले ही तालिका में कोई माइनस हो, हम ऐसा नहीं करते हैं इसे ध्यान में रखें.

सघनता:

पहले विकल्प में, हमें हेडर में केवल लंबाई संग्रहीत करने की आवश्यकता है; यदि हम चर-लंबाई पूर्णांक का उपयोग करते हैं, तो ज्यादातर मामलों में हम एक बाइट के साथ काम कर सकते हैं;
दूसरे विकल्प में हमें शुरुआती पता और लंबाई संग्रहीत करने की आवश्यकता है; रिकॉर्ड का आकार स्थिर होना चाहिए, मेरा अनुमान है कि प्रति रिकॉर्ड 4 बाइट्स (ऑफ़सेट के लिए दो बाइट्स, और लंबाई के लिए दो बाइट्स);
तीसरे विकल्प में रिकॉर्डिंग की शुरुआत को इंगित करने के लिए केवल एक वर्ण की आवश्यकता होती है, साथ ही परिरक्षण के कारण रिकॉर्डिंग स्वयं 1-2% बढ़ जाएगी। सामान्य तौर पर, पहले विकल्प के साथ लगभग समानता।

प्रारंभ में, मैंने दूसरे विकल्प को मुख्य माना (और कार्यान्वयन भी लिखा)। मैंने इसे तभी छोड़ा जब मैंने अंततः संपीड़न का उपयोग करने का निर्णय लिया।

शायद किसी दिन मैं अब भी इसी तरह के विकल्प का उपयोग करूंगा। उदाहरण के लिए, यदि मुझे पृथ्वी और मंगल ग्रह के बीच यात्रा करने वाले जहाज के लिए डेटा भंडारण से निपटना है, तो विश्वसनीयता, ब्रह्मांडीय विकिरण, के लिए पूरी तरह से अलग आवश्यकताएं होंगी ...

तीसरे विकल्प के लिए: मैंने इसे कार्यान्वयन की कठिनाई के लिए केवल इसलिए दो स्टार दिए क्योंकि मुझे परिरक्षण के साथ खिलवाड़ करना, प्रक्रिया में लंबाई बदलना आदि पसंद नहीं है। हां, शायद मैं पक्षपाती हूं, लेकिन मुझे कोड लिखना होगा - अपने आप को कुछ ऐसा करने के लिए मजबूर क्यों करें जो आपको पसंद नहीं है।

सारांश: हम दक्षता और कार्यान्वयन में आसानी के कारण "लंबाई वाले हेडर - परिवर्तनीय लंबाई के डेटा" श्रृंखला के रूप में भंडारण विकल्प चुनते हैं।

लेखन संचालन की सफलता की निगरानी के लिए बिट फ़ील्ड का उपयोग करना

मुझे अब याद नहीं है कि मुझे यह विचार कहां से मिला, लेकिन यह कुछ इस तरह दिखता है:
प्रत्येक प्रविष्टि के लिए, हम झंडे संग्रहीत करने के लिए कई बिट्स आवंटित करते हैं।
जैसा कि हमने पहले कहा, मिटाने के बाद सभी बिट्स 1s से भर जाते हैं, और हम 1 को 0 में बदल सकते हैं, लेकिन इसके विपरीत नहीं। इसलिए "ध्वज सेट नहीं है" के लिए हम 1 का उपयोग करते हैं, "ध्वज सेट है" के लिए हम 0 का उपयोग करते हैं।

वैरिएबल-लंबाई रिकॉर्ड को फ़्लैश में डालने पर यह कैसा दिख सकता है:

ध्वज सेट करें "लंबाई रिकॉर्डिंग शुरू हो गई है";
लंबाई रिकॉर्ड करें;
"डेटा रिकॉर्डिंग शुरू हो गई है" ध्वज सेट करें;
हम डेटा रिकॉर्ड करते हैं;
"रिकॉर्डिंग समाप्त" ध्वज सेट करें।

इसके अलावा, हमारे पास कुल 4 बिट फ़्लैग के लिए एक "त्रुटि उत्पन्न हुई" फ़्लैग होगा।

इस मामले में, हमारे पास दो स्थिर स्थितियाँ हैं "1111" - रिकॉर्डिंग शुरू नहीं हुई है और "1000" - रिकॉर्डिंग सफल रही; रिकॉर्डिंग प्रक्रिया में अप्रत्याशित रुकावट की स्थिति में, हमें मध्यवर्ती स्थिति प्राप्त होगी, जिसे हम पता लगा सकते हैं और संसाधित कर सकते हैं।

दृष्टिकोण दिलचस्प है, लेकिन यह केवल अचानक बिजली कटौती और इसी तरह की विफलताओं से बचाता है, जो निश्चित रूप से महत्वपूर्ण है, लेकिन यह संभावित विफलताओं का एकमात्र (या यहां तक कि मुख्य) कारण से बहुत दूर है।

सारांश: आइए एक अच्छे समाधान की तलाश में आगे बढ़ें।

चेकसम

चेकसम यह सुनिश्चित करना भी संभव बनाता है (उचित संभावना के साथ) कि हम वही पढ़ रहे हैं जो लिखा जाना चाहिए था। और, ऊपर चर्चा की गई बिट फ़ील्ड के विपरीत, वे हमेशा काम करते हैं।

यदि हम समस्याओं के संभावित स्रोतों की सूची पर विचार करते हैं जिनकी हमने ऊपर चर्चा की है, तो चेकसम किसी त्रुटि को उसके मूल की परवाह किए बिना पहचानने में सक्षम है (शायद, दुर्भावनापूर्ण एलियंस को छोड़कर - वे चेकसम भी बना सकते हैं).

इसलिए यदि हमारा लक्ष्य यह सत्यापित करना है कि डेटा बरकरार है, तो चेकसम एक अच्छा विचार है।

चेकसम की गणना के लिए एल्गोरिदम की पसंद ने कोई प्रश्न नहीं उठाया - सीआरसी। एक ओर, गणितीय गुण कुछ प्रकार की त्रुटियों को 100% पकड़ना संभव बनाते हैं; दूसरी ओर, यादृच्छिक डेटा पर यह एल्गोरिदम आमतौर पर टकराव की संभावना को सैद्धांतिक सीमा से अधिक नहीं दिखाता है . यह सबसे तेज़ एल्गोरिदम नहीं हो सकता है, न ही टकराव की संख्या के मामले में यह हमेशा न्यूनतम होता है, लेकिन इसमें एक बहुत ही महत्वपूर्ण गुण है: मेरे द्वारा किए गए परीक्षणों में, ऐसे कोई पैटर्न नहीं थे जिनमें यह स्पष्ट रूप से विफल रहा हो। इस मामले में स्थिरता मुख्य गुण है।

वॉल्यूमेट्रिक अध्ययन का उदाहरण: भाग 1, भाग 2 (narod.ru से लिंक, क्षमा करें).

हालाँकि, चेकसम का चयन करने का कार्य पूरा नहीं हुआ है; सीआरसी चेकसम का एक पूरा परिवार है। आपको लंबाई तय करनी होगी और फिर एक बहुपद चुनना होगा।

चेकसम की लंबाई चुनना उतना आसान सवाल नहीं है जितना पहली नज़र में लगता है।

मुझे समझाने दीजिए:
आइए प्रत्येक बाइट में त्रुटि की संभावना ज्ञात करें और एक आदर्श चेकसम, आइए प्रति मिलियन रिकॉर्ड त्रुटियों की औसत संख्या की गणना करें:

डेटा, बाइट
चेकसम, बाइट
अज्ञात त्रुटियाँ
ग़लत त्रुटि का पता लगाना
कुल झूठी सकारात्मकता

1
0
1000
0
1000

1
1
4
999
1003

1
2
≈0
1997
1997

1
4
≈0
3990
3990

10
0
9955
0
9955

10
1
39
990
1029

10
2
≈0
1979
1979

10
4
≈0
3954
3954

1000
0
632305
0
632305

1000
1
2470
368
2838

1000
2
10
735
745

1000
4
≈0
1469
1469

ऐसा प्रतीत होता है कि सब कुछ सरल है - संरक्षित किए जा रहे डेटा की लंबाई के आधार पर, न्यूनतम गलत सकारात्मकता के साथ चेकसम की लंबाई चुनें - और चाल बैग में है।

हालाँकि, छोटे चेकसम के साथ एक समस्या उत्पन्न होती है: हालाँकि वे एकल बिट त्रुटियों का पता लगाने में अच्छे हैं, वे काफी उच्च संभावना के साथ पूरी तरह से यादृच्छिक डेटा को सही मान सकते हैं। हैबे का वर्णन करने वाला एक लेख पहले से ही मौजूद था वास्तविक जीवन में समस्या.

इसलिए, यादृच्छिक चेकसम मिलान को लगभग असंभव बनाने के लिए, आपको 32 बिट या उससे अधिक लंबाई वाले चेकसम का उपयोग करने की आवश्यकता है। (64 बिट से अधिक लंबाई के लिए, क्रिप्टोग्राफ़िक हैश फ़ंक्शंस का आमतौर पर उपयोग किया जाता है).

इस तथ्य के बावजूद कि मैंने पहले लिखा था कि हमें हर तरह से जगह बचाने की जरूरत है, हम अभी भी 32-बिट चेकसम का उपयोग करेंगे (16 बिट्स पर्याप्त नहीं हैं, टकराव की संभावना 0.01% से अधिक है; और 24 बिट्स, जैसा कि वे हैं) कहते हैं, न इधर के हैं, न उधर के) .

यहां एक आपत्ति उत्पन्न हो सकती है: क्या हमने संपीड़न चुनते समय प्रत्येक बाइट को सहेजा था ताकि अब एक बार में 4 बाइट दे सकें? क्या यह बेहतर नहीं होगा कि चेकसम को कंप्रेस या न जोड़ा जाए? बिल्कुल नहीं, कोई संपीड़न नहीं मतलब नहीं है, कि हमें सत्यनिष्ठा जाँच की आवश्यकता नहीं है।

बहुपद चुनते समय, हम पहिये का पुन: आविष्कार नहीं करेंगे, बल्कि अब लोकप्रिय सीआरसी-32सी लेंगे।
यह कोड 6 बाइट्स तक के पैकेट पर 22 बिट त्रुटियों का पता लगाता है (शायद हमारे लिए सबसे आम मामला), 4 बाइट्स तक के पैकेट पर 655 बिट त्रुटियां (हमारे लिए भी एक सामान्य मामला), 2 या पैकेट पर किसी भी विषम संख्या में बिट त्रुटियों का पता लगाता है। किसी भी उचित लंबाई का.

यदि किसी को विवरण में रुचि है

विकिपीडिया लेख सीआरसी के बारे में

कोड पैरामीटर सीआरसी-32सी पर कूपमैन वेबसाइट - शायद ग्रह पर अग्रणी सीआरसी विशेषज्ञ।

В उसका लेख वहाँ है एक और दिलचस्प कोड, जो हमारे लिए प्रासंगिक पैकेट लंबाई के लिए थोड़ा बेहतर पैरामीटर प्रदान करता है, लेकिन मैंने अंतर को महत्वपूर्ण नहीं माना, और मैं मानक और अच्छी तरह से शोध किए गए कोड के बजाय कस्टम कोड चुनने में सक्षम था।

साथ ही, चूंकि हमारा डेटा संपीड़ित है, इसलिए सवाल उठता है: क्या हमें संपीड़ित या असम्पीडित डेटा के चेकसम की गणना करनी चाहिए?

असम्पीडित डेटा के चेकसम की गणना के पक्ष में तर्क:

हमें अंततः डेटा भंडारण की सुरक्षा की जांच करने की आवश्यकता है - इसलिए हम इसे सीधे जांचते हैं (साथ ही, संपीड़न/डीकंप्रेसन के कार्यान्वयन में संभावित त्रुटियों, टूटी हुई मेमोरी के कारण होने वाली क्षति आदि की जांच की जाएगी);
ज़्लिब में डिफ्लेट एल्गोरिदम का कार्यान्वयन काफी परिपक्व है और नहीं करना चाहिए "टेढ़े" इनपुट डेटा के साथ गिरना; इसके अलावा, यह अक्सर इनपुट स्ट्रीम में त्रुटियों का स्वतंत्र रूप से पता लगाने में सक्षम होता है, जिससे किसी त्रुटि का पता न चलने की समग्र संभावना कम हो जाती है (एक संक्षिप्त रिकॉर्ड में एक बिट को उलटने के साथ एक परीक्षण किया गया, zlib ने एक त्रुटि का पता लगाया लगभग एक तिहाई मामलों में)।

असम्पीडित डेटा के चेकसम की गणना के विरुद्ध तर्क:

सीआरसी विशेष रूप से कुछ बिट त्रुटियों के लिए "अनुरूप" है जो फ्लैश मेमोरी की विशेषता है (संपीड़ित स्ट्रीम में थोड़ी त्रुटि आउटपुट स्ट्रीम में बड़े पैमाने पर बदलाव का कारण बन सकती है, जिस पर, विशुद्ध रूप से सैद्धांतिक रूप से, हम टकराव को "पकड़" सकते हैं);
मुझे संभावित रूप से टूटे हुए डेटा को डीकंप्रेसर में भेजने का विचार वास्तव में पसंद नहीं है, कौन जानता हैवह कैसे प्रतिक्रिया देगा.

इस परियोजना में, मैंने असम्पीडित डेटा के चेकसम को संग्रहीत करने की आम तौर पर स्वीकृत प्रथा से विचलित होने का निर्णय लिया।

सारांश: हम सीआरसी-32सी का उपयोग करते हैं, हम डेटा से चेकसम की गणना उस रूप में करते हैं जिसमें उन्हें फ्लैश करने के लिए लिखा जाता है (संपीड़न के बाद)।

फालतूपन

निरर्थक कोडिंग का उपयोग, निश्चित रूप से, डेटा हानि को समाप्त नहीं करता है, हालांकि, यह महत्वपूर्ण रूप से (अक्सर परिमाण के कई आदेशों द्वारा) अपरिवर्तनीय डेटा हानि की संभावना को कम कर सकता है।

त्रुटियों को ठीक करने के लिए हम विभिन्न प्रकार के अतिरेक का उपयोग कर सकते हैं।
हैमिंग कोड एकल बिट त्रुटियों को ठीक कर सकते हैं, रीड-सोलोमन कैरेक्टर कोड, चेकसम के साथ संयुक्त डेटा की कई प्रतियां, या RAID-6 जैसे एन्कोडिंग बड़े पैमाने पर भ्रष्टाचार की स्थिति में भी डेटा को पुनर्प्राप्त करने में मदद कर सकते हैं।
प्रारंभ में, मैं त्रुटि-प्रतिरोधी कोडिंग के व्यापक उपयोग के लिए प्रतिबद्ध था, लेकिन फिर मुझे एहसास हुआ कि हमें पहले यह पता होना चाहिए कि हम खुद को किन त्रुटियों से बचाना चाहते हैं, और फिर कोडिंग का चयन करें।

हमने पहले कहा था कि त्रुटियों को यथाशीघ्र पकड़ने की जरूरत है। हम किन बिंदुओं पर त्रुटियों का सामना कर सकते हैं?

अधूरी रिकॉर्डिंग (रिकॉर्डिंग के समय किसी कारण से बिजली बंद हो गई, रास्पबेरी जम गई, ...)
अफसोस, ऐसी त्रुटि की स्थिति में, केवल अमान्य रिकॉर्ड को अनदेखा करना और खोए हुए डेटा पर विचार करना बाकी है;
त्रुटियाँ लिखें (किसी कारण से, फ़्लैश मेमोरी में जो लिखा गया था वह वह नहीं था जो लिखा गया था)
यदि हम रिकॉर्डिंग के तुरंत बाद परीक्षण करते हैं तो हम ऐसी त्रुटियों का तुरंत पता लगा सकते हैं;
भंडारण के दौरान मेमोरी में डेटा का विरूपण;
पढ़ने में त्रुटियाँ
इसे ठीक करने के लिए, यदि चेकसम मेल नहीं खाता है, तो रीडिंग को कई बार दोहराना पर्याप्त है।

अर्थात्, केवल तीसरे प्रकार की त्रुटियों (भंडारण के दौरान डेटा का सहज भ्रष्टाचार) को त्रुटि-प्रतिरोधी कोडिंग के बिना ठीक नहीं किया जा सकता है। ऐसा लगता है कि ऐसी त्रुटियाँ अभी भी बेहद असंभावित हैं।

सारांश: निरर्थक कोडिंग को छोड़ने का निर्णय लिया गया था, लेकिन यदि ऑपरेशन इस निर्णय की त्रुटि दिखाता है, तो मुद्दे पर विचार करने के लिए वापस आएं (विफलताओं पर पहले से ही संचित आंकड़ों के साथ, जो इष्टतम प्रकार के कोडिंग को चुनने की अनुमति देगा)।

अन्य

निःसंदेह, लेख का प्रारूप हमें प्रारूप के प्रत्येक अंश को उचित ठहराने की अनुमति नहीं देता है (और मेरी ताकत पहले ही ख़त्म हो चुकी है), इसलिए मैं संक्षेप में उन कुछ बिंदुओं पर चर्चा करूंगा जिन पर पहले चर्चा नहीं की गई थी।

सभी पृष्ठों को "समान" बनाने का निर्णय लिया गया
अर्थात्, मेटाडेटा, अलग-अलग थ्रेड आदि के साथ कोई विशेष पृष्ठ नहीं होंगे, बल्कि एक एकल थ्रेड होगा जो बारी-बारी से सभी पृष्ठों को फिर से लिखता है।
यह सुनिश्चित करता है कि पृष्ठों पर एकसमान घिसाव हो, विफलता का एक भी बिंदु न हो, और मुझे यह पसंद है;
प्रारूप का संस्करण प्रदान करना अनिवार्य है।
हेडर में संस्करण संख्या के बिना एक प्रारूप बुरा है!
पेज हेडर में एक निश्चित मैजिक नंबर (हस्ताक्षर) के साथ एक फ़ील्ड जोड़ने के लिए पर्याप्त है, जो उपयोग किए गए प्रारूप के संस्करण को इंगित करेगा (मुझे नहीं लगता कि व्यवहार में इनकी संख्या एक दर्जन भी होगी);
रिकॉर्ड्स के लिए एक वैरिएबल-लेंथ हेडर का उपयोग करें (जिनमें से बहुत सारे हैं), ज्यादातर मामलों में इसे 1 बाइट लंबा बनाने का प्रयास करें;
हेडर की लंबाई और संपीड़ित रिकॉर्ड के ट्रिम किए गए हिस्से की लंबाई को एनकोड करने के लिए, वेरिएबल-लेंथ बाइनरी कोड का उपयोग करें।

बहुत मदद की ऑनलाइन जनरेटर हफ़मैन कोड. कुछ ही मिनटों में हम आवश्यक परिवर्तनीय लंबाई कोड का चयन करने में सक्षम हो गए।

डेटा भंडारण प्रारूप का विवरण

बाइट क्रम

एक बाइट से बड़े फ़ील्ड को बिग-एंडियन प्रारूप (नेटवर्क बाइट ऑर्डर) में संग्रहीत किया जाता है, यानी 0x1234 को 0x12, 0x34 के रूप में लिखा जाता है।

पृष्ठ पर अंक लगाना

सभी फ़्लैश मेमोरी को समान आकार के पृष्ठों में विभाजित किया गया है।

डिफ़ॉल्ट पृष्ठ आकार 32Kb है, लेकिन मेमोरी चिप के कुल आकार के 1/4 से अधिक नहीं (4MB चिप के लिए, 128 पृष्ठ प्राप्त होते हैं)।

प्रत्येक पृष्ठ दूसरों से स्वतंत्र रूप से डेटा संग्रहीत करता है (अर्थात, एक पृष्ठ का डेटा दूसरे पृष्ठ के डेटा का संदर्भ नहीं देता है)।

सभी पृष्ठों को प्राकृतिक क्रम में (पते के आरोही क्रम में) क्रमांकित किया गया है, संख्या 0 से शुरू होता है (पृष्ठ शून्य पते 0 से शुरू होता है, पहला पृष्ठ 32Kb से शुरू होता है, दूसरा पृष्ठ 64Kb से शुरू होता है, आदि)

मेमोरी चिप का उपयोग चक्रीय बफर (रिंग बफर) के रूप में किया जाता है, यानी पहले लेखन पृष्ठ संख्या 0 पर जाता है, फिर संख्या 1, ..., जब हम अंतिम पृष्ठ भरते हैं, तो एक नया चक्र शुरू होता है और पृष्ठ शून्य से रिकॉर्डिंग जारी रहती है .

पेज के अंदर

पेज की शुरुआत में, एक 4-बाइट पेज हेडर संग्रहीत किया जाता है, फिर एक हेडर चेकसम (CRC-32C), फिर रिकॉर्ड "हेडर, डेटा, चेकसम" प्रारूप में संग्रहीत किए जाते हैं।

पृष्ठ शीर्षक (आरेख में गंदा हरा) में निम्न शामिल हैं:

दो-बाइट मैजिक नंबर फ़ील्ड (प्रारूप संस्करण का एक संकेत भी)
प्रारूप के वर्तमान संस्करण के लिए इसकी गणना इस प्रकार की जाती है 0xed00 ⊕ номер страницы;
दो-बाइट काउंटर "पेज संस्करण" (मेमोरी पुनर्लेखन चक्र संख्या)।

पृष्ठ पर प्रविष्टियाँ संपीड़ित रूप में संग्रहीत की जाती हैं (डिफ्लेट एल्गोरिदम का उपयोग किया जाता है)। एक पृष्ठ पर सभी रिकॉर्ड एक थ्रेड में संपीड़ित होते हैं (एक सामान्य शब्दकोश का उपयोग किया जाता है), और प्रत्येक नए पृष्ठ पर संपीड़न नए सिरे से शुरू होता है। अर्थात्, किसी भी रिकॉर्ड को डीकंप्रेस करने के लिए, इस पृष्ठ (और केवल इस एक) के सभी पिछले रिकॉर्ड की आवश्यकता होती है।

प्रत्येक रिकॉर्ड को Z_SYNC_FLUSH ध्वज के साथ संपीड़ित किया जाएगा, और संपीड़ित स्ट्रीम के अंत में 4 बाइट्स 0x00, 0x00, 0xff, 0xff होंगे, संभवतः एक या दो और शून्य बाइट्स से पहले।
फ़्लैश मेमोरी में लिखते समय हम इस अनुक्रम (4, 5 या 6 बाइट्स लंबे) को छोड़ देते हैं।

रिकॉर्ड हेडर 1, 2 या 3 बाइट्स संग्रहीत करता है:

एक बिट (टी) रिकॉर्ड के प्रकार को दर्शाता है: 0 - संदर्भ, 1 - लॉग;
1 से 7 बिट्स तक एक परिवर्तनीय लंबाई फ़ील्ड (एस), हेडर की लंबाई और "पूंछ" को परिभाषित करता है जिसे डीकंप्रेसन के लिए रिकॉर्ड में जोड़ा जाना चाहिए;
रिकॉर्ड लंबाई (एल)।

एस मान तालिका:

S
हेडर की लंबाई, बाइट्स
लिखने पर खारिज, बाइट

0
1
5 (00 00 00 ff ff)

10
1
6 (00 00 00 00 ff ff)

110
2
4 (00 00 ff ff)

1110
2
5 (00 00 00 ff ff)

11110
2
6 (00 00 00 00 ff ff)

1111100
3
4 (00 00 ff ff)

1111101
3
5 (00 00 00 ff ff)

1111110
3
6 (00 00 00 00 ff ff)

मैंने वर्णन करने की कोशिश की, मुझे नहीं पता कि यह कितना स्पष्ट निकला:

पीला यहां टी फ़ील्ड को इंगित करता है, सफेद एस फ़ील्ड को, हरा एल (बाइट्स में संपीड़ित डेटा की लंबाई), नीला संपीड़ित डेटा को, लाल संपीड़ित डेटा के अंतिम बाइट्स को इंगित करता है जो फ्लैश मेमोरी में नहीं लिखे गए हैं।

इस प्रकार, हम एक बाइट में सबसे सामान्य लंबाई (संपीड़ित रूप में 63+5 बाइट्स तक) के रिकॉर्ड हेडर लिख सकते हैं।

प्रत्येक रिकॉर्ड के बाद, एक CRC-32C चेकसम संग्रहीत किया जाता है, जिसमें पिछले चेकसम का उलटा मान प्रारंभिक मान (init) के रूप में उपयोग किया जाता है।

सीआरसी में "अवधि" की संपत्ति है, निम्नलिखित सूत्र काम करता है (प्रक्रिया में प्लस या माइनस बिट व्युत्क्रम): .
यानी, वास्तव में, हम इस पृष्ठ पर हेडर और डेटा के सभी पिछले बाइट्स की सीआरसी की गणना करते हैं।

चेकसम के ठीक बाद अगले रिकॉर्ड का हेडर है।

हेडर को इस तरह से डिज़ाइन किया गया है कि इसका पहला बाइट हमेशा 0x00 और 0xff से भिन्न होता है (यदि हेडर के पहले बाइट के बजाय हमें 0xff मिलता है, तो इसका मतलब है कि यह एक अप्रयुक्त क्षेत्र है; 0x00 एक त्रुटि का संकेत देता है)।

उदाहरण एल्गोरिदम

फ़्लैश मेमोरी से पढ़ना

कोई भी रीडिंग चेकसम चेक के साथ आती है।
यदि चेकसम मेल नहीं खाता है, तो सही डेटा पढ़ने की उम्मीद में रीडिंग को कई बार दोहराया जाता है।

(यह समझ में आता है, लिनक्स NOR फ़्लैश से रीड को कैश नहीं करता है, परीक्षण किया गया)

फ़्लैश मेमोरी में लिखें

हम डेटा रिकॉर्ड करते हैं.
आइए उन्हें पढ़ें.

यदि पढ़ा गया डेटा लिखित डेटा से मेल नहीं खाता है, तो हम क्षेत्र को शून्य से भर देते हैं और एक त्रुटि का संकेत देते हैं।

संचालन के लिए एक नया माइक्रोक्रिकिट तैयार करना

आरंभीकरण के लिए, संस्करण 1 वाला एक हेडर पहले (या बल्कि शून्य) पृष्ठ पर लिखा जाता है।
उसके बाद, प्रारंभिक संदर्भ इस पृष्ठ पर लिखा जाता है (इसमें मशीन का यूयूआईडी और डिफ़ॉल्ट सेटिंग्स शामिल हैं)।

बस, फ़्लैश मेमोरी उपयोग के लिए तैयार है।

मशीन लोड हो रही है

लोड करते समय, प्रत्येक पेज के पहले 8 बाइट्स (हेडर + सीआरसी) पढ़े जाते हैं, अज्ञात मैजिक नंबर या गलत सीआरसी वाले पेजों को नजरअंदाज कर दिया जाता है।
"सही" पृष्ठों में से, अधिकतम संस्करण वाले पृष्ठ चुने जाते हैं, और सबसे अधिक संख्या वाला पृष्ठ उनमें से लिया जाता है।
पहला रिकॉर्ड पढ़ा जाता है, सीआरसी की शुद्धता और "संदर्भ" ध्वज की उपस्थिति की जाँच की जाती है। यदि सब कुछ ठीक है, तो यह पृष्ठ वर्तमान माना जाता है। यदि नहीं, तो हम पिछले पृष्ठ पर तब तक वापस जाते हैं जब तक हमें "लाइव" पृष्ठ नहीं मिल जाता।
और पाए गए पृष्ठ पर हमने सभी रिकॉर्ड पढ़े, जिनका उपयोग हम "संदर्भ" ध्वज के साथ करते हैं।
ज़्लिब शब्दकोश सहेजें (इस पृष्ठ पर जोड़ने के लिए इसकी आवश्यकता होगी)।

बस, डाउनलोड पूरा हो गया है, संदर्भ बहाल हो गया है, आप काम कर सकते हैं।

एक जर्नल प्रविष्टि जोड़ना

हम Z_SYNC_FLUSH को निर्दिष्ट करते हुए सही शब्दकोश के साथ रिकॉर्ड को संपीड़ित करते हैं। हम देखते हैं कि संपीड़ित रिकॉर्ड वर्तमान पृष्ठ पर फिट बैठता है या नहीं।
यदि यह फिट नहीं बैठता (या पृष्ठ पर सीआरसी त्रुटियाँ थीं), तो एक नया पृष्ठ शुरू करें (नीचे देखें)।
हम रिकॉर्ड और सीआरसी लिखते हैं। यदि कोई त्रुटि होती है, तो एक नया पृष्ठ प्रारंभ करें।

नया पृष्ठ

हम न्यूनतम संख्या के साथ एक निःशुल्क पृष्ठ का चयन करते हैं (हम एक निःशुल्क पृष्ठ को हेडर में गलत चेकसम वाला या मौजूदा संस्करण से कम संस्करण वाला पृष्ठ मानते हैं)। यदि ऐसे कोई पृष्ठ नहीं हैं, तो उनमें से न्यूनतम संख्या वाले पृष्ठ का चयन करें जिनका संस्करण वर्तमान पृष्ठ के बराबर है।
हम चयनित पृष्ठ मिटा देते हैं. हम 0xff के साथ सामग्री की जाँच करते हैं। यदि कुछ ग़लत है, तो अगला निःशुल्क पृष्ठ लें, आदि।
हम मिटाए गए पृष्ठ पर एक हेडर लिखते हैं, पहली प्रविष्टि संदर्भ की वर्तमान स्थिति है, अगली अलिखित लॉग प्रविष्टि है (यदि कोई है)।

प्रारूप प्रयोज्यता

मेरी राय में, यह NOR फ़्लैश में किसी भी अधिक या कम संपीड़ित सूचना स्ट्रीम (सादा पाठ, JSON, MessagePack, CBOR, संभवतः प्रोटोबफ) को संग्रहीत करने के लिए एक अच्छा प्रारूप साबित हुआ।

बेशक, प्रारूप SLC NOR फ़्लैश के लिए "अनुरूप" है।

इसका उपयोग उच्च BER मीडिया जैसे NAND या MLC NOR के साथ नहीं किया जाना चाहिए (क्या ऐसी मेमोरी बिक्री के लिए भी उपलब्ध है? मैंने इसका उल्लेख केवल सुधार कोड पर कार्यों में देखा है).

इसके अलावा, इसका उपयोग उन उपकरणों के साथ नहीं किया जाना चाहिए जिनके पास अपना स्वयं का एफटीएल है: यूएसबी फ्लैश, एसडी, माइक्रोएसडी, आदि (ऐसी मेमोरी के लिए मैंने 512 बाइट्स के पृष्ठ आकार, प्रत्येक पृष्ठ की शुरुआत में एक हस्ताक्षर और अद्वितीय रिकॉर्ड संख्याओं के साथ एक प्रारूप बनाया - कभी-कभी सरल अनुक्रमिक रीडिंग द्वारा "गड़बड़" फ्लैश ड्राइव से सभी डेटा को पुनर्प्राप्त करना संभव था).

कार्यों के आधार पर, प्रारूप का उपयोग फ्लैश ड्राइव पर 128Kbit (16Kb) से 1Gbit (128MB) तक बदलाव किए बिना किया जा सकता है। यदि चाहें, तो आप इसे बड़े चिप्स पर उपयोग कर सकते हैं, लेकिन संभवतः आपको पृष्ठ आकार को समायोजित करने की आवश्यकता होगी (लेकिन यहां आर्थिक व्यवहार्यता का सवाल पहले से ही उठता है; बड़ी मात्रा में NOR फ्लैश की कीमत उत्साहजनक नहीं है).

यदि किसी को प्रारूप दिलचस्प लगता है और वह इसे एक खुले प्रोजेक्ट में उपयोग करना चाहता है, तो लिखें, मैं समय ढूंढने का प्रयास करूंगा, कोड को पॉलिश करूंगा और इसे जीथब पर पोस्ट करूंगा।

निष्कर्ष

जैसा कि आप देख सकते हैं, अंत में प्रारूप सरल निकला और उबाऊ भी.

एक लेख में मेरे दृष्टिकोण के विकास को प्रतिबिंबित करना कठिन है, लेकिन मेरा विश्वास करें: शुरू में मैं कुछ परिष्कृत, अविनाशी बनाना चाहता था, जो निकटता में परमाणु विस्फोट से भी बचने में सक्षम हो। हालाँकि, तर्क (मुझे आशा है) फिर भी जीत गया और धीरे-धीरे प्राथमिकताएँ सरलता और सघनता की ओर स्थानांतरित हो गईं।

क्या ऐसा हो सकता है कि मैं ग़लत था? हाँ यकीनन। उदाहरण के लिए, यह अच्छी तरह से पता चल सकता है कि हमने निम्न-गुणवत्ता वाले माइक्रो-सर्किट का एक बैच खरीदा है। या किसी अन्य कारण से उपकरण विश्वसनीयता की अपेक्षाओं पर खरा नहीं उतरेगा।

क्या मेरे पास इसके लिए कोई योजना है? मुझे लगता है कि लेख पढ़ने के बाद आपको इसमें कोई संदेह नहीं रह जाएगा कि कोई योजना है। और अकेले भी नहीं.

थोड़ा अधिक गंभीर नोट पर, प्रारूप को एक कार्यशील विकल्प और "ट्रायल बैलून" दोनों के रूप में विकसित किया गया था।

फिलहाल मेज पर सब कुछ ठीक काम कर रहा है, वस्तुतः अगले दिन समाधान तैनात किया जाएगा (लगभग) सैकड़ों उपकरणों पर, आइए देखें कि "मुकाबला" ऑपरेशन में क्या होता है (सौभाग्य से, मुझे आशा है कि प्रारूप आपको विफलताओं का विश्वसनीय रूप से पता लगाने की अनुमति देता है; ताकि आप पूर्ण आंकड़े एकत्र कर सकें)। कुछ महीनों में निष्कर्ष निकालना संभव होगा (और यदि आप बदकिस्मत हैं, तो पहले भी).

यदि, उपयोग के परिणामों के आधार पर, गंभीर समस्याओं का पता चलता है और सुधार की आवश्यकता होती है, तो मैं निश्चित रूप से इसके बारे में लिखूंगा।

साहित्य

मैं प्रयुक्त कार्यों की लंबी थका देने वाली सूची नहीं बनाना चाहता था; आख़िरकार, हर किसी के पास Google है।

यहां मैंने उन निष्कर्षों की एक सूची छोड़ने का फैसला किया जो मुझे विशेष रूप से दिलचस्प लगे, लेकिन धीरे-धीरे वे सीधे लेख के पाठ में चले गए, और एक आइटम सूची में बना रहा:

उपयोगिता infgen लेखक ज़्लिब से। डिफ्लेट/ज़लिब/जीज़िप अभिलेखागार की सामग्री को स्पष्ट रूप से प्रदर्शित कर सकता है। यदि आपको डिफ्लेट (या जीज़िप) प्रारूप की आंतरिक संरचना से निपटना है, तो मैं इसकी अत्यधिक अनुशंसा करता हूं।

स्रोत: www.habr.com

NOR फ़्लैश में रिंग बफ़र का मेरा कार्यान्वयन