প্রাগঐতিহাসিক

আমাদের নিজস্ব ডিজাইনের ভেন্ডিং মেশিন রয়েছে। রাস্পবেরি পাই এবং একটি পৃথক বোর্ডে কিছু তারের ভিতরে। একটি মুদ্রা গ্রহণকারী, একটি বিল গ্রহণকারী, একটি ব্যাংক টার্মিনাল সংযুক্ত রয়েছে... সবকিছু একটি স্ব-লিখিত প্রোগ্রাম দ্বারা নিয়ন্ত্রিত হয়৷ সম্পূর্ণ কাজের ইতিহাস একটি ফ্ল্যাশ ড্রাইভে (মাইক্রোএসডি) একটি লগে লেখা হয়, যা পরে ইন্টারনেটের মাধ্যমে (একটি ইউএসবি মডেম ব্যবহার করে) সার্ভারে প্রেরণ করা হয়, যেখানে এটি একটি ডাটাবেসে সংরক্ষণ করা হয়। বিক্রয় তথ্য 1c এ লোড করা হয়, পর্যবেক্ষণের জন্য একটি সাধারণ ওয়েব ইন্টারফেসও রয়েছে ইত্যাদি।

অর্থাৎ, জার্নালটি অত্যাবশ্যক - অ্যাকাউন্টিং (রাজস্ব, বিক্রয়, ইত্যাদি), নিরীক্ষণ (সব ধরণের ব্যর্থতা এবং অন্যান্য ফোর্স ম্যাজেউর পরিস্থিতিতে); এটি, কেউ বলতে পারে, এই মেশিন সম্পর্কে আমাদের কাছে সমস্ত তথ্য।

সমস্যা

ফ্ল্যাশ ড্রাইভগুলি নিজেদেরকে খুব অবিশ্বস্ত ডিভাইস হিসাবে দেখায়। তারা ঈর্ষণীয় নিয়মিততার সাথে ব্যর্থ হয়। এটি মেশিনের ডাউনটাইম এবং (যদি কোনো কারণে লগ অনলাইনে স্থানান্তরিত না হতে পারে) উভয়ই ডেটা ক্ষতির দিকে নিয়ে যায়।

এটি ফ্ল্যাশ ড্রাইভ ব্যবহারের প্রথম অভিজ্ঞতা নয়, এর আগে শতাধিক ডিভাইস সহ আরেকটি প্রকল্প ছিল, যেখানে ম্যাগাজিনটি ইউএসবি ফ্ল্যাশ ড্রাইভে সংরক্ষণ করা হয়েছিল, সেখানে নির্ভরযোগ্যতার সাথেও সমস্যা ছিল, অনেক সময় ব্যর্থতার সংখ্যা ছিল। এক মাস কয়েক ডজন ছিল। আমরা এসএলসি মেমরি সহ ব্র্যান্ডেড সহ বিভিন্ন ফ্ল্যাশ ড্রাইভ চেষ্টা করেছি এবং কিছু মডেল অন্যদের তুলনায় বেশি নির্ভরযোগ্য, তবে ফ্ল্যাশ ড্রাইভগুলি প্রতিস্থাপন করা সমস্যাটির আমূল সমাধান করেনি।

সতর্কতা লংরিড ! আপনি যদি "কেন" এ আগ্রহী না হন তবে শুধুমাত্র "কিভাবে" এ আগ্রহী হন, আপনি সরাসরি যেতে পারেন শেষে নিবন্ধ।

রায়

প্রথম যে জিনিসটি মনে আসে তা হল: মাইক্রোএসডি ত্যাগ করুন, উদাহরণস্বরূপ, একটি এসএসডি ইনস্টল করুন এবং এটি থেকে বুট করুন। তাত্ত্বিকভাবে সম্ভব, সম্ভবত, কিন্তু তুলনামূলকভাবে ব্যয়বহুল, এবং এতটা নির্ভরযোগ্য নয় (একটি USB-SATA অ্যাডাপ্টার যোগ করা হয়েছে; বাজেট SSD-এর ব্যর্থতার পরিসংখ্যানও উত্সাহজনক নয়)।

USB HDD এছাড়াও একটি বিশেষ আকর্ষণীয় সমাধান মত দেখায় না.

অতএব, আমরা এই বিকল্পটিতে এসেছি: মাইক্রোএসডি থেকে বুটিং ছেড়ে দিন, তবে সেগুলিকে কেবল-পঠন মোডে ব্যবহার করুন এবং অপারেশন লগ (এবং হার্ডওয়্যারের একটি নির্দিষ্ট অংশের জন্য অনন্য অন্যান্য তথ্য - সিরিয়াল নম্বর, সেন্সর ক্রমাঙ্কন ইত্যাদি) অন্য কোথাও সংরক্ষণ করুন। .

রাস্পবেরিগুলির জন্য শুধুমাত্র পঠনযোগ্য এফএসের বিষয়টি ইতিমধ্যে ভিতরে এবং বাইরে অধ্যয়ন করা হয়েছে, আমি এই নিবন্ধে বাস্তবায়নের বিশদগুলিতে থাকব না (তবে যদি আগ্রহ থাকে তবে আমি এই বিষয়ে একটি ছোট নিবন্ধ লিখব). আমি শুধুমাত্র একটি পয়েন্ট লক্ষ্য করতে চাই যে ব্যক্তিগত অভিজ্ঞতা এবং যারা ইতিমধ্যে এটি বাস্তবায়ন করেছে তাদের পর্যালোচনা থেকে, নির্ভরযোগ্যতার একটি লাভ আছে। হ্যাঁ, ব্রেকডাউনগুলি থেকে সম্পূর্ণরূপে পরিত্রাণ পাওয়া অসম্ভব, তবে তাদের ফ্রিকোয়েন্সি উল্লেখযোগ্যভাবে হ্রাস করা বেশ সম্ভব। এবং কার্ডগুলি একীভূত হচ্ছে, যা পরিষেবা কর্মীদের জন্য প্রতিস্থাপনকে অনেক সহজ করে তোলে।

হার্ডওয়্যার অংশ

মেমরি টাইপ পছন্দ সম্পর্কে কোন বিশেষ সন্দেহ ছিল না - নর ফ্ল্যাশ.
যুক্তি:

• সহজ সংযোগ (প্রায়শই SPI বাস, যা আপনার ইতিমধ্যেই ব্যবহারের অভিজ্ঞতা রয়েছে, তাই কোনও হার্ডওয়্যার সমস্যা পূর্বাভাস হয় না);
• হাস্যকর মূল্য;
• স্ট্যান্ডার্ড অপারেটিং প্রোটোকল (বাস্তবায়নটি ইতিমধ্যেই লিনাক্স কার্নেলে রয়েছে, আপনি যদি চান তবে আপনি একটি তৃতীয় পক্ষ নিতে পারেন, যা উপস্থিত রয়েছে, বা এমনকি নিজের লিখতে পারেন, ভাগ্যক্রমে সবকিছুই সহজ);
• নির্ভরযোগ্যতা এবং সম্পদ:
  একটি সাধারণ ডেটাশিট থেকে: ডেটা 20 বছরের জন্য সংরক্ষণ করা হয়, প্রতিটি ব্লকের জন্য 100000 মুছে ফেলার চক্র;
  তৃতীয় পক্ষের উত্স থেকে: অত্যন্ত কম BER, ত্রুটি সংশোধন কোডের প্রয়োজন নেই বলে মনে করে (কিছু কাজ NOR এর জন্য ECC বিবেচনা করে, কিন্তু সাধারণত তারা এখনও MLC NOR মানে; এটিও ঘটে).

আসুন ভলিউম এবং সম্পদের জন্য প্রয়োজনীয়তা অনুমান করি।

আমি অনেক দিনের জন্য ডেটা সংরক্ষণের নিশ্চয়তা দিতে চাই। এটি প্রয়োজনীয় যাতে কোনও যোগাযোগ সমস্যার ক্ষেত্রে, বিক্রয় ইতিহাস হারিয়ে না যায়। আমরা এই সময়ের মধ্যে 5 দিনের উপর ফোকাস করব (এমনকি সপ্তাহান্তে এবং ছুটির দিনগুলি বিবেচনায় নিয়ে) সমস্যা সমাধান করা যেতে পারে।

আমরা বর্তমানে প্রতিদিন প্রায় 100kb লগ সংগ্রহ করি (3-4 হাজার এন্ট্রি), কিন্তু ধীরে ধীরে এই সংখ্যা বাড়ছে - বিস্তারিত বাড়ছে, নতুন ইভেন্ট যোগ করা হচ্ছে। এছাড়াও, কখনও কখনও বিস্ফোরণ হয় (কিছু সেন্সর মিথ্যা ইতিবাচক দিয়ে স্প্যামিং শুরু করে, উদাহরণস্বরূপ)। আমরা 10 হাজার রেকর্ডের জন্য গণনা করব 100 বাইট প্রতিটি - প্রতিদিন মেগাবাইট।

মোট, 5MB পরিষ্কার (ভালভাবে সংকুচিত) ডেটা বেরিয়ে আসে। তাদের কাছে আরও (মোটামুটি অনুমান) 1MB পরিষেবা ডেটা।

অর্থাৎ, যদি আমরা কম্প্রেশন ব্যবহার না করি তাহলে আমাদের একটি 8MB চিপ দরকার, অথবা যদি আমরা এটি ব্যবহার করি তাহলে 4MB। এই ধরনের মেমরির জন্য বেশ বাস্তবসম্মত সংখ্যা।

সম্পদের জন্য: যদি আমরা পরিকল্পনা করি যে পুরো মেমরিটি প্রতি 5 দিনে একবারের বেশি পুনঃলিখন করা হবে না, তাহলে 10 বছরের বেশি পরিষেবাতে আমরা এক হাজারেরও কম পুনর্লিখন চক্র পাই।
আমি আপনাকে মনে করিয়ে দিই যে প্রস্তুতকারক এক লক্ষ প্রতিশ্রুতি দেয়।

NOR বনাম NAND সম্পর্কে একটু

আজ, অবশ্যই, NAND মেমরি অনেক বেশি জনপ্রিয়, কিন্তু আমি এই প্রকল্পের জন্য এটি ব্যবহার করব না: NAND, NOR-এর বিপরীতে, অগত্যা ত্রুটি সংশোধন কোড, খারাপ ব্লকগুলির একটি টেবিল, ইত্যাদি ব্যবহার করা প্রয়োজন, এবং এর পা। NAND চিপ সাধারণত অনেক বেশি।

NOR এর অসুবিধাগুলির মধ্যে রয়েছে:

• ছোট ভলিউম (এবং, সেই অনুযায়ী, প্রতি মেগাবাইটে উচ্চ মূল্য);
• কম যোগাযোগের গতি (মূলত একটি সিরিয়াল ইন্টারফেস ব্যবহার করা হয়, সাধারণত SPI বা I2C);
• ধীর মুছে ফেলা (ব্লক আকারের উপর নির্ভর করে, এটি এক সেকেন্ডের ভগ্নাংশ থেকে কয়েক সেকেন্ড পর্যন্ত লাগে)।

মনে হচ্ছে আমাদের জন্য সমালোচনামূলক কিছুই নেই, তাই আমরা চালিয়ে যাচ্ছি।

বিবরণ আকর্ষণীয় হলে, microcircuit নির্বাচন করা হয়েছে at25df321a (তবে, এটি গুরুত্বহীন, বাজারে অনেকগুলি অ্যানালগ রয়েছে যা পিনআউট এবং কমান্ড সিস্টেমের সাথে সামঞ্জস্যপূর্ণ; এমনকি যদি আমরা একটি ভিন্ন নির্মাতার থেকে একটি মাইক্রোসার্কিট ইনস্টল করতে চাই এবং/অথবা একটি ভিন্ন আকার, সবকিছু পরিবর্তন না করেই কাজ করবে কোড).

আমি লিনাক্স কার্নেলে তৈরি ড্রাইভার ব্যবহার করি; রাস্পবেরিতে, ডিভাইস ট্রি ওভারলে সমর্থনের জন্য ধন্যবাদ, সবকিছু খুব সহজ - আপনাকে কম্পাইল করা ওভারলেকে /boot/overlays-এ রাখতে হবে এবং /boot/config.txt-এ সামান্য পরিবর্তন করতে হবে।

উদাহরণ dts ফাইল

সত্যি বলতে, আমি নিশ্চিত নই যে এটি ত্রুটি ছাড়াই লেখা হয়েছে, তবে এটি কাজ করে।

/*
 * 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টি পা রয়েছে, যার মধ্যে আমাদের মাটি, শক্তি, এসপিআই (CS, SI, SO, SCK) প্রয়োজন ); স্তরগুলি রাস্পবেরি পাই-এর মতোই, কোনও অতিরিক্ত তারের প্রয়োজন নেই - শুধুমাত্র নির্দেশিত 6 পিন সংযুক্ত করুন৷

সমস্যা গঠন

যথারীতি, সমস্যা বিবৃতিটি বেশ কয়েকটি পুনরাবৃত্তির মধ্য দিয়ে যায় এবং আমার কাছে মনে হয় এটি পরবর্তীটির জন্য সময়। সুতরাং আসুন থামুন, ইতিমধ্যে যা লেখা হয়েছে তা একত্রিত করুন এবং ছায়ায় রয়ে যাওয়া বিবরণগুলি পরিষ্কার করুন।

তাই, আমরা সিদ্ধান্ত নিয়েছি যে লগটি SPI NOR Flash-এ সংরক্ষণ করা হবে।

যারা জানেন না তাদের জন্য NOR ফ্ল্যাশ কি?

এটি অ-উদ্বায়ী মেমরি যা দিয়ে আপনি তিনটি অপারেশন করতে পারেন:

1. পড়া:
   সবচেয়ে সাধারণ পঠন: আমরা ঠিকানা প্রেরণ করি এবং যতগুলি বাইট প্রয়োজন ততগুলি পড়ি;
2. রেকর্ড:
   NOR ফ্ল্যাশে লেখা একটি নিয়মিত মত দেখায়, তবে এটির একটি বিশেষত্ব রয়েছে: আপনি শুধুমাত্র 1 থেকে 0 পরিবর্তন করতে পারেন, কিন্তু উল্টো নয়৷ উদাহরণস্বরূপ, যদি আমাদের একটি মেমরি সেলে 0x55 থাকে, তবে এটিতে 0x0f লেখার পরে, 0x05 ইতিমধ্যেই সেখানে সংরক্ষণ করা হবে। (ঠিক নীচে টেবিল দেখুন);
3. মুছে দিন:
   অবশ্যই, আমাদের বিপরীত অপারেশন করতে সক্ষম হতে হবে - 0 থেকে 1 পরিবর্তন করুন, এটিই ইরেজ অপারেশনের জন্য। প্রথম দুটির বিপরীতে, এটি বাইট দিয়ে নয়, ব্লকগুলির সাথে কাজ করে (নির্বাচিত চিপে সর্বনিম্ন ইরেজ ব্লক 4kb)। ইরেজ পুরো ব্লককে ধ্বংস করে দেয় এবং এটি 0 থেকে 1 পরিবর্তন করার একমাত্র উপায়। অতএব, ফ্ল্যাশ মেমরির সাথে কাজ করার সময়, আপনাকে প্রায়ই ডেটা স্ট্রাকচারগুলিকে ইরেজ ব্লকের সীমানায় সারিবদ্ধ করতে হবে।
   নওর ফ্ল্যাশে রেকর্ডিং:

বাইনারি ডেটা

এটি ছিল
01010101

নথিভুক্ত
00001111

হয়ে গেছে
00000101

লগ নিজেই পরিবর্তনশীল দৈর্ঘ্যের রেকর্ডের একটি ক্রম উপস্থাপন করে। একটি রেকর্ডের সাধারণ দৈর্ঘ্য প্রায় 30 বাইট (যদিও এমন রেকর্ড যা কখনও কখনও দৈর্ঘ্যে কয়েক কিলোবাইট হয়)। এই ক্ষেত্রে, আমরা তাদের সাথে কেবল বাইটের সেট হিসাবে কাজ করি, কিন্তু, যদি আপনি আগ্রহী হন, CBOR রেকর্ডের ভিতরে ব্যবহার করা হয়

লগ ছাড়াও, আমাদের কিছু "সেটিং" তথ্য সঞ্চয় করতে হবে, উভয়ই আপডেট করা এবং নয়: একটি নির্দিষ্ট ডিভাইস আইডি, সেন্সর ক্যালিব্রেশন, একটি "ডিভাইস সাময়িকভাবে অক্ষম করা হয়েছে" পতাকা ইত্যাদি।
এই তথ্যটি মূল-মান রেকর্ডের একটি সেট, যা CBOR-এও সংরক্ষিত। আমাদের কাছে এই তথ্যের বেশি কিছু নেই (সর্বোচ্চ কয়েক কিলোবাইট), এবং এটি কদাচিৎ আপডেট করা হয়।
যা অনুসরণ করে আমরা এটিকে প্রসঙ্গ বলব।

যদি আমরা মনে করি এই নিবন্ধটি কোথা থেকে শুরু হয়েছে, তাহলে নির্ভরযোগ্য ডেটা সঞ্চয়স্থান নিশ্চিত করা এবং সম্ভব হলে, হার্ডওয়্যার ব্যর্থতা/ডেটা দুর্নীতির ক্ষেত্রেও ক্রমাগত অপারেশন নিশ্চিত করা খুবই গুরুত্বপূর্ণ।

সমস্যার উৎস কি বিবেচনা করা যেতে পারে?

• লিখুন/মুছে ফেলার ক্রিয়াকলাপের সময় পাওয়ার বন্ধ করুন। এটি "কাকবারের বিরুদ্ধে কোন কৌশল নেই" এর বিভাগ থেকে এসেছে।
  থেকে তথ্য আলোচনা স্ট্যাকএক্সচেঞ্জে: যখন ফ্ল্যাশের সাথে কাজ করার সময় পাওয়ার বন্ধ হয়ে যায়, তখন উভয়ই মুছে ফেলুন (1 এ সেট করুন) এবং লিখুন (0 তে সেট করুন) অনির্ধারিত আচরণের দিকে নিয়ে যায়: ডেটা লেখা যেতে পারে, আংশিকভাবে লেখা যেতে পারে (বলুন, আমরা 10 বাইট/80 বিট স্থানান্তর করেছি) , কিন্তু এখনও শুধুমাত্র 45 বিট লেখা যাবে না), এটাও সম্ভব যে কিছু বিট একটি "মধ্যবর্তী" অবস্থায় থাকবে (পড়া 0 এবং 1 উভয়ই তৈরি করতে পারে);
• ফ্ল্যাশ মেমরি নিজেই ত্রুটি.
  BER, যদিও খুব কম, শূন্যের সমান হতে পারে না;
• বাসের ত্রুটি
  এসপিআই-এর মাধ্যমে প্রেরিত ডেটা কোনওভাবেই সুরক্ষিত নয়; একক বিট ত্রুটি এবং সিঙ্ক্রোনাইজেশন ত্রুটি উভয়ই ঘটতে পারে - বিটগুলির ক্ষতি বা সন্নিবেশ (যা ব্যাপক ডেটা বিকৃতির দিকে পরিচালিত করে);
• অন্যান্য ত্রুটি/গ্লচ
  কোডে ত্রুটি, রাস্পবেরি গ্লিচ, এলিয়েন হস্তক্ষেপ...

আমি প্রয়োজনীয়তাগুলি প্রণয়ন করেছি, যার পরিপূর্ণতা, আমার মতে, নির্ভরযোগ্যতা নিশ্চিত করার জন্য প্রয়োজনীয়:

• রেকর্ডগুলি অবিলম্বে ফ্ল্যাশ মেমরিতে যেতে হবে, বিলম্বিত লেখাগুলি বিবেচনা করা হয় না; - যদি কোনও ত্রুটি ঘটে তবে এটি যত তাড়াতাড়ি সম্ভব সনাক্ত এবং প্রক্রিয়া করা উচিত; - সিস্টেমটিকে, যদি সম্ভব হয়, ত্রুটিগুলি থেকে পুনরুদ্ধার করতে হবে৷
  (জীবন থেকে একটি উদাহরণ "এটি কীভাবে হওয়া উচিত নয়", যা আমি মনে করি প্রত্যেকেরই সম্মুখীন হয়েছে: একটি জরুরী রিবুট করার পরে, ফাইল সিস্টেম "ভাঙা" হয় এবং অপারেটিং সিস্টেম বুট হয় না)

ধারনা, পন্থা, প্রতিফলন

যখন আমি এই সমস্যাটি নিয়ে ভাবতে শুরু করি, তখন আমার মাথায় অনেক ধারনা উড়ে যায়, উদাহরণস্বরূপ:

• ডেটা কম্প্রেশন ব্যবহার করুন;
• চতুর ডেটা স্ট্রাকচার ব্যবহার করুন, উদাহরণস্বরূপ, রেকর্ডের শিরোনামগুলিকে রেকর্ড থেকে আলাদাভাবে সংরক্ষণ করা, যাতে কোনও রেকর্ডে কোনও ত্রুটি থাকলে, আপনি কোনও সমস্যা ছাড়াই বাকিগুলি পড়তে পারেন;
• পাওয়ার বন্ধ হয়ে গেলে রেকর্ডিং সম্পূর্ণ হওয়া নিয়ন্ত্রণ করতে বিট ক্ষেত্র ব্যবহার করুন;
• সবকিছুর জন্য চেকসাম সংরক্ষণ করুন;
• কিছু ধরনের শব্দ-প্রতিরোধী কোডিং ব্যবহার করুন।

এর মধ্যে কিছু ধারণা ব্যবহার করা হয়েছিল, কিছু পরিত্যাগ করার সিদ্ধান্ত নেওয়া হয়েছিল। এর ক্রমানুযায়ী যান.

তথ্য সংকোচন

আমরা জার্নালে যে ইভেন্টগুলি রেকর্ড করি তা বেশ একই রকম এবং পুনরাবৃত্তিযোগ্য ("একটি 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. উপরে আলোচিত অ্যালগরিদমের পরিবর্তে অভিধান কম্প্রেশন ব্যবহার করে প্রতিটি রেকর্ডকে সংকুচিত করুন।
   এটি একটি সম্পূর্ণরূপে কাজ করার বিকল্প, কিন্তু আমি এটি পছন্দ করি না। কম-বেশি শালীন স্তরের কম্প্রেশন নিশ্চিত করার জন্য, অভিধানটিকে অবশ্যই নির্দিষ্ট ডেটার জন্য "উপযুক্ত" হতে হবে; যেকোনো পরিবর্তন কম্প্রেশন স্তরকে বিপর্যয়করভাবে পতনের দিকে নিয়ে যাবে। হ্যাঁ, অভিধানের একটি নতুন সংস্করণ তৈরি করে সমস্যাটি সমাধান করা যেতে পারে, তবে এটি একটি মাথাব্যথা - আমাদের অভিধানের সমস্ত সংস্করণ সংরক্ষণ করতে হবে; প্রতিটি এন্ট্রিতে আমাদের নির্দেশ করতে হবে অভিধানের কোন সংস্করণের সাথে এটি সংকুচিত হয়েছে...
2. "শাস্ত্রীয়" অ্যালগরিদম ব্যবহার করে প্রতিটি রেকর্ড সংকুচিত করুন, কিন্তু অন্যদের থেকে স্বাধীনভাবে।
   বিবেচনাধীন কম্প্রেশন অ্যালগরিদমগুলি এই আকারের রেকর্ডগুলির সাথে কাজ করার জন্য ডিজাইন করা হয়নি (দশ বাইট), কম্প্রেশন অনুপাত স্পষ্টভাবে 1 এর কম হবে (অর্থাৎ, সংকোচনের পরিবর্তে ডেটা ভলিউম বাড়ানো);
3. প্রতিটি রেকর্ডিংয়ের পরে ফ্লাশ করুন।
   অনেক কম্প্রেশন লাইব্রেরি FLUSH-এর জন্য সমর্থন করে। এটি একটি কমান্ড (বা কম্প্রেশন পদ্ধতির একটি প্যারামিটার), যা পাওয়ার পরে আর্কাইভার একটি সংকুচিত স্ট্রীম গঠন করে যাতে এটি পুনরুদ্ধার করতে ব্যবহার করা যেতে পারে সব সংকুচিত ডেটা যা ইতিমধ্যে প্রাপ্ত হয়েছে। যেমন একটি এনালগ sync ফাইল সিস্টেমে বা commit এসকিউএল-এ।
   যা গুরুত্বপূর্ণ তা হল পরবর্তী কম্প্রেশন ক্রিয়াকলাপগুলি সঞ্চিত অভিধান ব্যবহার করতে সক্ষম হবে এবং কম্প্রেশন অনুপাত আগের সংস্করণের মতো ক্ষতিগ্রস্থ হবে না।

আমি মনে করি এটি স্পষ্ট যে আমি তৃতীয় বিকল্পটি বেছে নিয়েছি, আসুন এটি আরও বিশদে দেখি।

পাওয়া গেছে দুর্দান্ত নিবন্ধ zlib মধ্যে FLUSH সম্পর্কে.

আমি নিবন্ধের উপর ভিত্তি করে একটি হাঁটু পরীক্ষা করেছি, একটি বাস্তব ডিভাইস থেকে 70 হাজার লগ এন্ট্রি নিয়েছি, যার পৃষ্ঠার আকার 60Kb (আমরা পরে পৃষ্ঠা আকারে ফিরে আসব) প্রাপ্ত:

কাঁচা তথ্য
কম্প্রেশন gzip -9 (কোনও ফ্লাশ নয়)
Z_PARTIAL_FLUSH সহ zlib
Z_SYNC_FLUSH সহ zlib

আয়তন, কেবি
1692
40
352
604

প্রথম নজরে, ফ্লুশ দ্বারা অবদান করা মূল্য অত্যধিক বেশি, কিন্তু বাস্তবে আমাদের কাছে খুব কমই পছন্দ আছে - হয় একেবারে সংকুচিত না করা, বা ফ্লাশের সাথে সংকুচিত করা (এবং খুব কার্যকরভাবে)। আমাদের ভুলে যাওয়া উচিত নয় যে আমাদের কাছে 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 FF FF.

আপনি সহজেই দেখতে পাচ্ছেন, এই 4 বাইটের আগে শেষ ব্লকে 3 থেকে 10 শূন্য বিট রয়েছে। যাইহোক, অনুশীলন দেখিয়েছে যে আসলে কমপক্ষে 10টি শূন্য বিট রয়েছে।

দেখা যাচ্ছে যে এই ধরনের সংক্ষিপ্ত ডেটা ব্লকগুলি সাধারণত (সর্বদা?) টাইপ 1 (নির্দিষ্ট ব্লক) ব্লক ব্যবহার করে এনকোড করা হয়, যা অগত্যা 7 শূন্য বিট দিয়ে শেষ হয়, মোট 10-17 গ্যারান্টিযুক্ত শূন্য বিট দেয় (এবং বাকিগুলি থাকবে) প্রায় 50% এর সম্ভাবনা সহ শূন্য হতে হবে)।

সুতরাং, পরীক্ষার ডেটাতে, 100% ক্ষেত্রে 0x00, 0x00, 0xff, 0xff এর আগে একটি শূন্য বাইট থাকে এবং এক তৃতীয়াংশেরও বেশি ক্ষেত্রে দুটি শূন্য বাইট থাকে (সম্ভবত সত্য যে আমি বাইনারি CBOR ব্যবহার করি, এবং JSON পাঠ্য ব্যবহার করার সময়, টাইপ 2 - গতিশীল ব্লকের ব্লকগুলি আরও সাধারণ হবে, যথাক্রমে, 0x00, 0x00, 0xff, 0xff এর আগে অতিরিক্ত শূন্য বাইট ছাড়া ব্লকগুলি সম্মুখীন হবে).

মোট, উপলভ্য পরীক্ষার ডেটা ব্যবহার করে, 250Kb-এর কম কমপ্রেসড ডেটাতে ফিট করা সম্ভব।

আপনি বিট জাগলিং করে আরও কিছুটা বাঁচাতে পারেন: আপাতত আমরা ব্লকের শেষে কয়েকটি শূন্য বিটের উপস্থিতি উপেক্ষা করি, ব্লকের শুরুতে কয়েকটি বিটও পরিবর্তন হয় না...
কিন্তু তারপরে আমি বন্ধ করার একটি দৃঢ়-ইচ্ছাকৃত সিদ্ধান্ত নিয়েছিলাম, অন্যথায় এই হারে আমি আমার নিজস্ব আর্কাইভার বিকাশ করতে পারতাম।

মোট, আমার পরীক্ষার ডেটা থেকে আমি প্রতি লেখায় 3-4 বাইট পেয়েছি, কম্প্রেশন অনুপাত 6:1-এর বেশি হতে দেখা গেছে। আমি সৎ হব: আমি এমন ফলাফল আশা করিনি; আমার মতে, 2:1 এর চেয়ে ভাল কিছু ইতিমধ্যেই একটি ফলাফল যা সংকোচনের ব্যবহারকে ন্যায়সঙ্গত করে।

সবকিছু ঠিক আছে, কিন্তু zlib (deflate) এখনও একটি পুরাতন, সু-প্রাপ্য এবং সামান্য পুরানো ধাঁচের কম্প্রেশন অ্যালগরিদম। অসংকুচিত ডেটা স্ট্রীমের শেষ 32Kbটি অভিধান হিসাবে ব্যবহৃত হয় তা আজ অদ্ভুত দেখাচ্ছে (অর্থাৎ, যদি কিছু ডেটা ব্লক 40Kb আগে ইনপুট স্ট্রীমের সাথে খুব মিল থাকে, তবে এটি আবার সংরক্ষণাগারভুক্ত হতে শুরু করবে, এবং পূর্ববর্তী ঘটনার উল্লেখ করবে না)। ফ্যাশনেবল আধুনিক আর্কাইভারগুলিতে, অভিধানের আকার প্রায়শই কিলোবাইটের পরিবর্তে মেগাবাইটে পরিমাপ করা হয়।

তাই আমরা আমাদের আর্কাইভারের মিনি-স্টাডি চালিয়ে যাচ্ছি।

এরপরে আমরা bzip2 পরীক্ষা করেছি (মনে রাখবেন, FLUSH ছাড়া এটি প্রায় 100:1 এর একটি দুর্দান্ত কম্প্রেশন অনুপাত দেখিয়েছিল)। দুর্ভাগ্যবশত, এটি FLUSH-এর সাথে খুব খারাপভাবে পারফর্ম করেছে; সংকুচিত ডেটার আকার অসঙ্কুচিত ডেটার চেয়ে বড় হতে দেখা গেছে।

ব্যর্থতার কারণ সম্পর্কে আমার অনুমান

Libbz2 শুধুমাত্র একটি ফ্লাশ বিকল্প অফার করে, যা অভিধানটি পরিষ্কার করে বলে মনে হচ্ছে (zlib-এ Z_FULL_FLUSH-এর অনুরূপ); এর পরে কোনও কার্যকর সংকোচনের কথা নেই।

এবং সর্বশেষ পরীক্ষা করা হয়েছিল zstd. পরামিতিগুলির উপর নির্ভর করে, এটি হয় জিজিপের স্তরে সংকুচিত হয়, তবে অনেক দ্রুত বা জিজিপের চেয়ে ভাল।

হায়, ফ্লাশের সাথে এটি খুব ভাল কাজ করেনি: সংকুচিত ডেটার আকার ছিল প্রায় 700Kb।

Я একটি প্রশ্ন জিজ্ঞাসা প্রজেক্টের গিথুব পৃষ্ঠায়, আমি একটি উত্তর পেয়েছি যে আপনাকে সংকুচিত ডেটার প্রতিটি ব্লকের জন্য 10 বাইট পর্যন্ত পরিষেবা ডেটা গণনা করা উচিত, যা প্রাপ্ত ফলাফলের কাছাকাছি; ডিফ্লেট ধরার কোনও উপায় নেই।

আমি আর্কাইভারগুলির সাথে আমার পরীক্ষায় এই মুহুর্তে থামার সিদ্ধান্ত নিয়েছি (আমাকে মনে করিয়ে দিই যে xz, lzip, lzo, lz4 ফ্লুশ ছাড়া পরীক্ষার পর্যায়েও নিজেকে দেখায়নি, এবং আমি আরও বিদেশী কম্প্রেশন অ্যালগরিদম বিবেচনা করিনি)।

এর সংরক্ষণাগার সমস্যা ফিরে আসা যাক.

দ্বিতীয়টি (যেমন তারা ক্রমানুসারে বলে, মান অনুসারে নয়) সমস্যা হল যে সংকুচিত ডেটা হল একটি একক স্ট্রীম, যেখানে ক্রমাগত পূর্ববর্তী বিভাগগুলির উল্লেখ রয়েছে। এইভাবে, যদি সংকুচিত ডেটার একটি অংশ ক্ষতিগ্রস্ত হয়, তবে আমরা কেবল অসঙ্কোচিত ডেটার সংশ্লিষ্ট ব্লকগুলিই হারাবো না, পরবর্তী সমস্তগুলিও হারাবো।

এই সমস্যা সমাধানের জন্য একটি পদ্ধতি আছে:

1. সমস্যাটি ঘটতে বাধা দিন - সংকুচিত ডেটাতে অপ্রয়োজনীয়তা যোগ করুন, যা আপনাকে ত্রুটিগুলি সনাক্ত করতে এবং সংশোধন করতে দেবে; আমরা এই বিষয়ে পরে কথা বলব;
2. কোনো সমস্যা হলে পরিণতি কমিয়ে দিন
   আমরা আগেই বলেছি যে আপনি প্রতিটি ডেটা ব্লক স্বাধীনভাবে সংকুচিত করতে পারেন এবং সমস্যাটি নিজেই অদৃশ্য হয়ে যাবে (একটি ব্লকের ডেটার ক্ষতি শুধুমাত্র এই ব্লকের জন্য ডেটা হারাতে পারে)। যাইহোক, এটি একটি চরম ক্ষেত্রে যেখানে ডেটা সংকোচন অকার্যকর হবে। বিপরীত চরম: আমাদের চিপের সমস্ত 4MB একটি একক সংরক্ষণাগার হিসাবে ব্যবহার করুন, যা আমাদেরকে চমৎকার কম্প্রেশন দেবে, কিন্তু ডেটা দুর্নীতির ক্ষেত্রে বিপর্যয়কর পরিণতি।
   হ্যাঁ, নির্ভরযোগ্যতার ক্ষেত্রে একটি আপস প্রয়োজন। কিন্তু আমাদের অবশ্যই মনে রাখতে হবে যে আমরা অত্যন্ত কম BER সহ অ-উদ্বায়ী মেমরির জন্য একটি ডেটা স্টোরেজ ফর্ম্যাট তৈরি করছি এবং 20 বছরের ঘোষিত ডেটা স্টোরেজ সময়কাল।

পরীক্ষা-নিরীক্ষার সময়, আমি আবিষ্কার করেছি যে কম্প্রেশন লেভেলে কমবেশি লক্ষণীয় ক্ষতি 10 KB-এর চেয়ে কম কমপ্রেসড ডেটার ব্লকগুলিতে শুরু হয়।
এটি পূর্বে উল্লেখ করা হয়েছিল যে ব্যবহৃত মেমরিটি পৃষ্ঠাযুক্ত; আমি কোন কারণ দেখি না কেন "এক পৃষ্ঠা - সংকুচিত ডেটার এক ব্লক" চিঠিপত্র ব্যবহার করা উচিত নয়।

অর্থাৎ, ন্যূনতম যুক্তিসঙ্গত পৃষ্ঠার আকার হল 16Kb (পরিষেবার তথ্যের জন্য রিজার্ভ সহ)। যাইহোক, এই ধরনের একটি ছোট পৃষ্ঠার আকার সর্বাধিক রেকর্ড আকারের উপর উল্লেখযোগ্য সীমাবদ্ধতা আরোপ করে।

যদিও আমি এখনও সংকুচিত আকারে কয়েক কিলোবাইটের চেয়ে বড় রেকর্ড আশা করি না, আমি 32Kb পৃষ্ঠাগুলি ব্যবহার করার সিদ্ধান্ত নিয়েছি (প্রতি চিপে মোট 128 পৃষ্ঠার জন্য)।

সারাংশ:

• আমরা zlib (deflate) ব্যবহার করে সংকুচিত ডেটা সংরক্ষণ করি;
• প্রতিটি এন্ট্রির জন্য আমরা Z_SYNC_FLUSH সেট করি;
• প্রতিটি সংকুচিত রেকর্ডের জন্য, আমরা ট্রেলিং বাইট ট্রিম করি (যেমন 0x00, 0x00, 0xff, 0xff); হেডারে আমরা নির্দেশ করি কত বাইট আমরা কেটে ফেলি;
• আমরা 32Kb পৃষ্ঠাগুলিতে ডেটা সংরক্ষণ করি; পৃষ্ঠার ভিতরে সংকুচিত ডেটার একটি একক প্রবাহ রয়েছে; প্রতিটি পৃষ্ঠায় আমরা আবার কম্প্রেশন শুরু করি।

এবং, কম্প্রেশনের সাথে শেষ করার আগে, আমি আপনার দৃষ্টি আকর্ষণ করতে চাই যে আমাদের কাছে রেকর্ড প্রতি মাত্র কয়েক বাইট সংকুচিত ডেটা আছে, তাই পরিষেবার তথ্যকে স্ফীত না করা অত্যন্ত গুরুত্বপূর্ণ, প্রতিটি বাইট এখানে গণনা করা হয়।

ডেটা হেডার সংরক্ষণ করা

যেহেতু আমাদের কাছে পরিবর্তনশীল দৈর্ঘ্যের রেকর্ড রয়েছে, তাই আমাদের কোনোভাবে রেকর্ডের স্থান নির্ধারণ/সীমা নির্ধারণ করতে হবে।

আমি তিনটি পন্থা জানি:

1. সমস্ত রেকর্ড একটি অবিচ্ছিন্ন প্রবাহে সংরক্ষণ করা হয়, প্রথমে দৈর্ঘ্য সহ একটি রেকর্ড শিরোনাম থাকে এবং তারপরে রেকর্ডটি নিজেই।
   এই মূর্তিতে, শিরোনাম এবং ডেটা উভয়ই পরিবর্তনশীল দৈর্ঘ্যের হতে পারে।
   মূলত, আমরা একটি একক লিঙ্কযুক্ত তালিকা পাই যা সর্বদা ব্যবহৃত হয়;
2. শিরোনাম এবং রেকর্ড নিজেই পৃথক স্ট্রীম সংরক্ষণ করা হয়.
   ধ্রুব দৈর্ঘ্যের হেডার ব্যবহার করে, আমরা নিশ্চিত করি যে একটি হেডারের ক্ষতি অন্যদের প্রভাবিত না করে।
   একটি অনুরূপ পদ্ধতি ব্যবহার করা হয়, উদাহরণস্বরূপ, অনেক ফাইল সিস্টেমে;
3. রেকর্ডগুলি একটি অবিচ্ছিন্ন প্রবাহে সংরক্ষণ করা হয়, রেকর্ডের সীমানা একটি নির্দিষ্ট মার্কার দ্বারা নির্ধারিত হয় (অক্ষরের একটি অক্ষর/ক্রম যা ডেটা ব্লকের মধ্যে নিষিদ্ধ)। যদি রেকর্ডের ভিতরে একটি মার্কার থাকে, তবে আমরা এটিকে কিছু ক্রম দিয়ে প্রতিস্থাপন করি (এটি এস্কেপ করুন)।
   একটি অনুরূপ পদ্ধতি ব্যবহার করা হয়, উদাহরণস্বরূপ, পিপিপি প্রোটোকলে।

আমি ব্যাখ্যা করব।

অপশন 1:

এখানে সবকিছু খুব সহজ: রেকর্ডের দৈর্ঘ্য জেনে, আমরা পরবর্তী হেডারের ঠিকানা গণনা করতে পারি। সুতরাং আমরা শিরোনামগুলির মধ্য দিয়ে অগ্রসর হই যতক্ষণ না আমরা 0xff (মুক্ত এলাকা) বা পৃষ্ঠার শেষে ভরা একটি অঞ্চলের সম্মুখীন হই।

অপশন 2:

পরিবর্তনশীল রেকর্ডের দৈর্ঘ্যের কারণে, আমরা প্রতি পৃষ্ঠায় কত রেকর্ড (এবং তাই শিরোনাম) প্রয়োজন হবে তা আগে থেকে বলতে পারি না। আপনি বিভিন্ন পৃষ্ঠায় শিরোনাম এবং ডেটা নিজেরাই ছড়িয়ে দিতে পারেন, তবে আমি একটি ভিন্ন পদ্ধতি পছন্দ করি: আমরা শিরোনাম এবং ডেটা উভয়ই এক পৃষ্ঠায় রাখি, তবে শিরোনামগুলি (স্থির আকারের) পৃষ্ঠার শুরু থেকে আসে এবং ডেটা (পরিবর্তনশীল দৈর্ঘ্যের) শেষ থেকে আসে। যত তাড়াতাড়ি তারা "সাক্ষাত" (একটি নতুন প্রবেশের জন্য পর্যাপ্ত ফাঁকা জায়গা নেই), আমরা এই পৃষ্ঠাটিকে সম্পূর্ণ বিবেচনা করি।

অপশন 3:

হেডারে ডেটার অবস্থান সম্পর্কে দৈর্ঘ্য বা অন্যান্য তথ্য সংরক্ষণ করার দরকার নেই; রেকর্ডের সীমানা নির্দেশকারী মার্কারগুলিই যথেষ্ট। যাইহোক, লেখা/পড়ার সময় ডেটা প্রক্রিয়া করতে হবে।
আমি 0xff একটি মার্কার হিসাবে ব্যবহার করব (যা মুছে ফেলার পরে পৃষ্ঠাটি পূরণ করে), তাই মুক্ত এলাকাটিকে অবশ্যই ডেটা হিসাবে গণ্য করা হবে না।

তুলনামূলক তালিকা:

অপশন 1
অপশন 2
অপশন 3

ত্রুটি সহনশীলতা
-
+
+

ঘনত্ব
+
-
+

বাস্তবায়ন জটিলতা
*
**
**

বিকল্প 1-এর একটি মারাত্মক ত্রুটি রয়েছে: শিরোনামগুলির কোনওটি ক্ষতিগ্রস্ত হলে, পরবর্তী সমস্ত চেইনটি ধ্বংস হয়ে যায়। অবশিষ্ট বিকল্পগুলি আপনাকে ব্যাপক ক্ষতির ক্ষেত্রেও কিছু ডেটা পুনরুদ্ধার করতে দেয়।
তবে এখানে এটি মনে রাখা উপযুক্ত যে আমরা একটি সংকুচিত আকারে ডেটা সংরক্ষণ করার সিদ্ধান্ত নিয়েছি, এবং তাই আমরা একটি "ভাঙা" রেকর্ডের পরে পৃষ্ঠার সমস্ত ডেটা হারিয়ে ফেলি, তাই টেবিলে একটি বিয়োগ থাকলেও আমরা তা করি না। একাউন্টে নিতে

সংক্ষিপ্ততা:

• প্রথম বিকল্পে, আমাদের কেবল হেডারে দৈর্ঘ্য সংরক্ষণ করতে হবে; যদি আমরা পরিবর্তনশীল-দৈর্ঘ্য পূর্ণসংখ্যা ব্যবহার করি, তবে বেশিরভাগ ক্ষেত্রে আমরা একটি বাইট দিয়ে পেতে পারি;
• দ্বিতীয় বিকল্পে আমাদের প্রারম্ভিক ঠিকানা এবং দৈর্ঘ্য সংরক্ষণ করতে হবে; রেকর্ডটি অবশ্যই একটি ধ্রুবক আকার হতে হবে, আমি প্রতি রেকর্ডে 4 বাইট অনুমান করি (অফসেটের জন্য দুটি বাইট এবং দৈর্ঘ্যের জন্য দুটি বাইট);
• তৃতীয় বিকল্পটিতে রেকর্ডিংয়ের শুরু নির্দেশ করার জন্য শুধুমাত্র একটি অক্ষর প্রয়োজন, প্লাস শিল্ডিংয়ের কারণে রেকর্ডিং নিজেই 1-2% বৃদ্ধি পাবে। সাধারণভাবে, প্রথম বিকল্পের সাথে প্রায় সমতা।

প্রাথমিকভাবে, আমি দ্বিতীয় বিকল্পটিকে প্রধান হিসাবে বিবেচনা করেছি (এবং এমনকি বাস্তবায়ন লিখেছি)। আমি যখন শেষ পর্যন্ত কম্প্রেশন ব্যবহার করার সিদ্ধান্ত নিয়েছি তখনই আমি এটি পরিত্যাগ করেছি।

সম্ভবত কোন দিন আমি এখনও একটি অনুরূপ বিকল্প ব্যবহার করব। উদাহরণস্বরূপ, যদি আমাকে পৃথিবী এবং মঙ্গল গ্রহের মধ্যে ভ্রমণকারী একটি জাহাজের ডেটা স্টোরেজ নিয়ে কাজ করতে হয়, তাহলে নির্ভরযোগ্যতা, মহাজাগতিক বিকিরণ, ... এর জন্য সম্পূর্ণ ভিন্ন প্রয়োজনীয়তা থাকবে।

তৃতীয় বিকল্পের জন্য: বাস্তবায়নের অসুবিধার জন্য আমি এটিকে দুটি তারা দিয়েছি কারণ আমি শিল্ডিং, প্রক্রিয়ার দৈর্ঘ্য পরিবর্তন ইত্যাদি নিয়ে এলোমেলো করতে পছন্দ করি না। হ্যাঁ, সম্ভবত আমি পক্ষপাতদুষ্ট, কিন্তু আমাকে কোডটি লিখতে হবে - কেন নিজেকে এমন কিছু করতে বাধ্য করবেন যা আপনি পছন্দ করেন না।

সারাংশ: দক্ষতা এবং বাস্তবায়নের সহজতার কারণে আমরা "দৈর্ঘ্য সহ হেডার - পরিবর্তনশীল দৈর্ঘ্যের ডেটা" চেইন আকারে স্টোরেজ বিকল্পটি বেছে নিই।

লেখার ক্রিয়াকলাপগুলির সাফল্য নিরীক্ষণ করতে বিট ক্ষেত্রগুলি ব্যবহার করা

আমি এখন মনে করি না যে আমি ধারণাটি কোথায় পেয়েছি, তবে এটি এরকম কিছু দেখায়:
প্রতিটি এন্ট্রির জন্য, আমরা পতাকা সংরক্ষণের জন্য বেশ কয়েকটি বিট বরাদ্দ করি।
আমরা আগেই বলেছি, মুছে ফেলার পরে সমস্ত বিট 1s দিয়ে পূর্ণ হয় এবং আমরা 1 থেকে 0 পরিবর্তন করতে পারি, তবে উল্টো নয়। সুতরাং "পতাকা সেট করা নেই" এর জন্য আমরা 1 ব্যবহার করি, "পতাকা সেট করা হয়েছে" এর জন্য আমরা 0 ব্যবহার করি।

ফ্ল্যাশে একটি পরিবর্তনশীল-দৈর্ঘ্যের রেকর্ড স্থাপন করা দেখতে কেমন হতে পারে তা এখানে:

1. পতাকা সেট করুন "দৈর্ঘ্য রেকর্ডিং শুরু হয়েছে";
2. দৈর্ঘ্য রেকর্ড করুন;
3. "ডেটা রেকর্ডিং শুরু হয়েছে" পতাকা সেট করুন;
4. আমরা ডেটা রেকর্ড করি;
5. "রেকর্ডিং শেষ" পতাকা সেট করুন।

উপরন্তু, আমাদের একটি "ত্রুটি ঘটেছে" পতাকা থাকবে, মোট 4 বিট পতাকার জন্য।

এই ক্ষেত্রে, আমাদের দুটি স্থিতিশীল অবস্থা "1111" - রেকর্ডিং শুরু হয়নি এবং "1000" - রেকর্ডিং সফল হয়েছে; রেকর্ডিং প্রক্রিয়ার একটি অপ্রত্যাশিত বাধার ক্ষেত্রে, আমরা মধ্যবর্তী অবস্থাগুলি পাব, যা আমরা তারপর সনাক্ত করতে এবং প্রক্রিয়া করতে পারি।

পদ্ধতিটি আকর্ষণীয়, তবে এটি শুধুমাত্র হঠাৎ বিদ্যুৎ বিভ্রাট এবং অনুরূপ ব্যর্থতা থেকে রক্ষা করে, যা অবশ্যই গুরুত্বপূর্ণ, তবে এটি সম্ভাব্য ব্যর্থতার একমাত্র (বা এমনকি প্রধান) কারণ থেকে অনেক দূরে।

সারাংশ: আসুন একটি ভাল সমাধানের সন্ধানে এগিয়ে যাই।

চেকসাম

চেকসামগুলি নিশ্চিত করাও সম্ভব করে (যৌক্তিক সম্ভাবনা সহ) যে আমরা ঠিক কী লেখা উচিত ছিল তা পড়ছি। এবং, উপরে আলোচিত বিট ক্ষেত্রগুলির বিপরীতে, তারা সর্বদা কাজ করে।

যদি আমরা উপরে আলোচনা করা সমস্যার সম্ভাব্য উত্সগুলির তালিকা বিবেচনা করি, তাহলে চেকসাম তার উত্স নির্বিশেষে একটি ত্রুটি সনাক্ত করতে সক্ষম হয় (ব্যতীত, সম্ভবত, দূষিত এলিয়েনদের জন্য - তারা চেকসামও জাল করতে পারে).

সুতরাং আমাদের লক্ষ্য যদি যাচাই করা হয় যে ডেটা অক্ষত আছে, চেকসামগুলি একটি দুর্দান্ত ধারণা।

চেকসাম গণনার জন্য অ্যালগরিদমের পছন্দ কোন প্রশ্ন উত্থাপন করেনি - CRC। একদিকে, গাণিতিক বৈশিষ্ট্যগুলি নির্দিষ্ট ধরণের ত্রুটিগুলি 100% ধরা সম্ভব করে তোলে; অন্যদিকে, র্যান্ডম ডেটাতে এই অ্যালগরিদমটি সাধারণত তাত্ত্বিক সীমার চেয়ে বেশি নয় সংঘর্ষের সম্ভাবনা দেখায়। . এটি দ্রুততম অ্যালগরিদম নাও হতে পারে, বা সংঘর্ষের সংখ্যার ক্ষেত্রে এটি সর্বদা সর্বনিম্ন নয়, তবে এটির একটি খুব গুরুত্বপূর্ণ গুণ রয়েছে: আমি যে পরীক্ষাগুলির মুখোমুখি হয়েছি, সেখানে এমন কোনও নিদর্শন ছিল না যেখানে এটি স্পষ্টভাবে ব্যর্থ হয়েছে। স্থিতিশীলতা এই ক্ষেত্রে প্রধান গুণ।

একটি ভলিউমেট্রিক অধ্যয়নের উদাহরণ: অংশ 1, অংশ 2 (narod.ru লিঙ্ক, দুঃখিত).

যাইহোক, একটি চেকসাম নির্বাচন করার কাজটি সম্পূর্ণ নয়; CRC হল চেকসামগুলির একটি সম্পূর্ণ পরিবার। আপনি দৈর্ঘ্য সিদ্ধান্ত নিতে হবে, এবং তারপর একটি বহুপদ চয়ন করুন.

চেকসাম দৈর্ঘ্য নির্বাচন করা এতটা সহজ প্রশ্ন নয় যতটা প্রথম নজরে মনে হয়।

আমাকে ব্যাখ্যা করা যাক:
আমাদের প্রতিটি বাইটে একটি ত্রুটির সম্ভাবনা আছে এবং একটি আদর্শ চেকসাম, আসুন প্রতি মিলিয়ন রেকর্ডে গড় ত্রুটির সংখ্যা গণনা করি:

ডেটা, বাইট
চেকসাম, বাইট
অনাবিষ্কৃত ত্রুটি
মিথ্যা ত্রুটি সনাক্তকরণ
মোট মিথ্যা ইতিবাচক

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

দেখে মনে হবে যে সবকিছুই সহজ - ডেটা সুরক্ষিত হওয়ার দৈর্ঘ্যের উপর নির্ভর করে, ন্যূনতম ভুল ইতিবাচকতার সাথে চেকসামের দৈর্ঘ্য চয়ন করুন - এবং কৌশলটি ব্যাগে রয়েছে।

যাইহোক, সংক্ষিপ্ত চেকসামগুলির সাথে একটি সমস্যা দেখা দেয়: যদিও তারা একক বিট ত্রুটি সনাক্ত করতে ভাল, তারা মোটামুটি উচ্চ সম্ভাবনার সাথে সম্পূর্ণ র্যান্ডম ডেটাকে সঠিক হিসাবে গ্রহণ করতে পারে। Habree বর্ণনা করার জন্য ইতিমধ্যে একটি নিবন্ধ ছিল বাস্তব জীবনে সমস্যা.

অতএব, একটি র্যান্ডম চেকসাম ম্যাচ প্রায় অসম্ভব করতে, আপনাকে 32 বিট বা তার বেশি দৈর্ঘ্যের চেকসাম ব্যবহার করতে হবে। (64 বিটের বেশি দৈর্ঘ্যের জন্য, ক্রিপ্টোগ্রাফিক হ্যাশ ফাংশন সাধারণত ব্যবহার করা হয়).

যদিও আমি আগে লিখেছিলাম যে আমাদের যে কোনও উপায়ে স্থান বাঁচাতে হবে, আমরা এখনও একটি 32-বিট চেকসাম ব্যবহার করব (16 বিট যথেষ্ট নয়, সংঘর্ষের সম্ভাবনা 0.01% এর বেশি; এবং 24 বিট, যেমন তারা বলুন, এখানেও নেই এবং সেখানেও নেই)।

এখানে একটি আপত্তি উঠতে পারে: এখন একবারে 4 বাইট দেওয়ার জন্য কম্প্রেশন নির্বাচন করার সময় আমরা কি প্রতিটি বাইট সংরক্ষণ করেছি? চেকসাম সংকুচিত করা এবং যুক্ত না করা কি ভাল হবে না? অবশ্যই না, কোন সংকোচন নেই মানে এই নয়, যে আমাদের সততা যাচাইয়ের প্রয়োজন নেই।

একটি বহুপদ বাছাই করার সময়, আমরা চাকাটি পুনরায় উদ্ভাবন করব না, তবে এখন জনপ্রিয় CRC-32C গ্রহণ করব।
এই কোডটি 6 বাইট পর্যন্ত প্যাকেটগুলিতে 22 বিট ত্রুটি সনাক্ত করে (সম্ভবত আমাদের জন্য সবচেয়ে সাধারণ ক্ষেত্রে), 4 বাইট পর্যন্ত প্যাকেটে 655 বিট ত্রুটি (আমাদের জন্যও একটি সাধারণ ক্ষেত্রে), 2 বা প্যাকেটগুলিতে বিজোড় সংখ্যক বিট ত্রুটি যেকোনো যুক্তিসঙ্গত দৈর্ঘ্যের।

কেউ বিস্তারিত জানতে আগ্রহী হলে

উইকিপিডিয়া নিবন্ধ সিআরসি সম্পর্কে।

কোড প্যারামিটার crc-32c উপর কুপম্যান ওয়েবসাইট — সম্ভবত গ্রহের শীর্ষস্থানীয় সিআরসি বিশেষজ্ঞ।

В তার নিবন্ধ হল আরেকটি আকর্ষণীয় কোড, যা আমাদের জন্য প্রাসঙ্গিক প্যাকেটের দৈর্ঘ্যের জন্য সামান্য ভাল প্যারামিটার প্রদান করে, কিন্তু আমি পার্থক্যটিকে তাৎপর্যপূর্ণ বিবেচনা করিনি এবং আমি মানক এবং ভালভাবে গবেষণা করা কোডের পরিবর্তে কাস্টম কোড বেছে নিতে যথেষ্ট সক্ষম ছিলাম।

এছাড়াও, যেহেতু আমাদের ডেটা সংকুচিত হয়, তাই প্রশ্ন ওঠে: আমাদের কি সংকুচিত বা অসঙ্কোচিত ডেটার চেকসাম গণনা করা উচিত?

সংকুচিত ডেটার চেকসাম গণনা করার পক্ষে যুক্তি:

• আমাদের শেষ পর্যন্ত ডেটা স্টোরেজের নিরাপত্তা পরীক্ষা করতে হবে - তাই আমরা এটি সরাসরি পরীক্ষা করি (একই সময়ে, কম্প্রেশন/ডিকম্প্রেশন বাস্তবায়নে সম্ভাব্য ত্রুটি, ভাঙ্গা মেমরির কারণে ক্ষতি, ইত্যাদি চেক করা হবে);
• zlib-এ deflate অ্যালগরিদম একটি মোটামুটি পরিপক্ক বাস্তবায়ন আছে এবং উচিত না "কুটিল" ইনপুট ডেটার সাথে পড়ে; অধিকন্তু, এটি প্রায়শই ইনপুট স্ট্রীমে স্বাধীনভাবে ত্রুটি সনাক্ত করতে সক্ষম হয়, একটি ত্রুটি সনাক্ত না করার সামগ্রিক সম্ভাবনা হ্রাস করে (একটি সংক্ষিপ্ত রেকর্ডে একটি একক বিট উল্টে দিয়ে একটি পরীক্ষা করে, zlib একটি ত্রুটি সনাক্ত করেছে প্রায় এক তৃতীয়াংশ ক্ষেত্রে)।

সংকুচিত ডেটার চেকসাম গণনা করার বিরুদ্ধে আর্গুমেন্ট:

• সিআরসি বিশেষত ফ্ল্যাশ মেমরির বৈশিষ্ট্যযুক্ত কয়েকটি বিট ত্রুটির জন্য "উপযুক্ত" (একটি সংকুচিত প্রবাহে একটি বিট ত্রুটি আউটপুট স্ট্রীমে ব্যাপক পরিবর্তন ঘটাতে পারে, যার ভিত্তিতে, বিশুদ্ধভাবে তাত্ত্বিকভাবে, আমরা একটি সংঘর্ষকে "ধরতে" পারি);
• ডিকম্প্রেসারে সম্ভাব্য ভাঙা ডেটা পাস করার ধারণাটি আমি সত্যিই পছন্দ করি না, কে জানেতিনি কিভাবে প্রতিক্রিয়া করবেন।

এই প্রকল্পে, আমি অসংকোচিত ডেটার একটি চেকসাম সংরক্ষণ করার সাধারণভাবে গৃহীত অনুশীলন থেকে বিচ্যুত হওয়ার সিদ্ধান্ত নিয়েছি।

সারাংশ: আমরা CRC-32C ব্যবহার করি, আমরা ডেটা থেকে চেকসাম গণনা করি যে ফর্মে তারা ফ্ল্যাশ করার জন্য লেখা হয় (সংকোচনের পরে)।

অপ্রয়োজনীয়তা

অপ্রয়োজনীয় কোডিং ব্যবহার অবশ্যই ডেটা ক্ষতি দূর করে না, তবে, এটি উল্লেখযোগ্যভাবে (প্রায়শই মাত্রার অনেক আদেশ দ্বারা) অপরিবর্তনীয় ডেটা ক্ষতির সম্ভাবনা হ্রাস করতে পারে।

আমরা ত্রুটি সংশোধন করতে বিভিন্ন ধরনের অপ্রয়োজনীয়তা ব্যবহার করতে পারি।
হ্যামিং কোডগুলি একক বিট ত্রুটি সংশোধন করতে পারে, রিড-সলোমন অক্ষর কোড, চেকসামগুলির সাথে একত্রিত ডেটার একাধিক কপি, বা RAID-6 এর মতো এনকোডিংগুলি এমনকি ব্যাপক দুর্নীতির ক্ষেত্রেও ডেটা পুনরুদ্ধার করতে সহায়তা করতে পারে।
প্রাথমিকভাবে, আমি ত্রুটি-প্রতিরোধী কোডিং-এর ব্যাপক ব্যবহারে প্রতিশ্রুতিবদ্ধ ছিলাম, কিন্তু তারপরে আমি বুঝতে পেরেছিলাম যে আমরা প্রথমে আমাদের নিজেদেরকে কী ত্রুটি থেকে রক্ষা করতে চাই সে সম্পর্কে ধারণা থাকতে হবে এবং তারপরে কোডিং বেছে নিতে হবে।

আমরা আগেই বলেছি যে যত দ্রুত সম্ভব ভুল ধরতে হবে। কোন পয়েন্টে আমরা ত্রুটির সম্মুখীন হতে পারি?

1. অসমাপ্ত রেকর্ডিং (রেকর্ডিংয়ের সময় কিছু কারণে পাওয়ার বন্ধ ছিল, রাস্পবেরি হিমায়িত হয়ে গেছে, ...)
   হায়, এই জাতীয় ত্রুটির ক্ষেত্রে, যা অবশিষ্ট থাকে তা হল অবৈধ রেকর্ডগুলিকে উপেক্ষা করা এবং ডেটা হারিয়ে যাওয়া বিবেচনা করা;
2. লেখার ত্রুটি (কিছু কারণে, ফ্ল্যাশ মেমরিতে যা লেখা ছিল তা লেখা হয়নি)
   রেকর্ডিংয়ের পরপরই আমরা পরীক্ষা করে পড়লে আমরা এই ধরনের ত্রুটিগুলি অবিলম্বে সনাক্ত করতে পারি;
3. স্টোরেজের সময় মেমরিতে ডেটার বিকৃতি;
4. পড়ার ত্রুটি
   এটি সংশোধন করার জন্য, যদি চেকসাম মেলে না, তবে এটি বেশ কয়েকবার পড়ার পুনরাবৃত্তি করা যথেষ্ট।

অর্থাৎ, শুধুমাত্র তৃতীয় প্রকারের ত্রুটিগুলি (সঞ্চয়স্থানের সময় ডেটার স্বতঃস্ফূর্ত দুর্নীতি) ত্রুটি-প্রতিরোধী কোডিং ছাড়া সংশোধন করা যায় না। মনে হচ্ছে এই ধরনের ত্রুটি এখনও অত্যন্ত অসম্ভাব্য।

সারাংশ: অপ্রয়োজনীয় কোডিং ত্যাগ করার সিদ্ধান্ত নেওয়া হয়েছিল, কিন্তু যদি অপারেশন এই সিদ্ধান্তের ত্রুটি দেখায়, তাহলে সমস্যাটির বিবেচনায় ফিরে যান (ব্যর্থতার বিষয়ে ইতিমধ্যেই জমা হওয়া পরিসংখ্যান সহ, যা সর্বোত্তম ধরনের কোডিং বেছে নেওয়ার অনুমতি দেবে)।

অন্যান্য

অবশ্যই, নিবন্ধের বিন্যাস আমাদের বিন্যাসে প্রতিটি বিট ন্যায্যতা করার অনুমতি দেয় না (এবং আমার শক্তি ইতিমধ্যে ফুরিয়ে গেছে), তাই আমি সংক্ষিপ্তভাবে কিছু পয়েন্ট নিয়ে যাব যা আগে স্পর্শ করা হয়নি।

• সমস্ত পৃষ্ঠা "সমান" করার সিদ্ধান্ত নেওয়া হয়েছিল
  অর্থাৎ, মেটাডেটা, পৃথক থ্রেড ইত্যাদি সহ কোনও বিশেষ পৃষ্ঠা থাকবে না, তবে পরিবর্তে একটি একক থ্রেড যা পালাক্রমে সমস্ত পৃষ্ঠা পুনর্লিখন করে।
  এটি পৃষ্ঠাগুলিতে এমনকি পরিধান নিশ্চিত করে, ব্যর্থতার কোন একক পয়েন্ট, এবং আমি এটি পছন্দ করি;
• বিন্যাসের সংস্করণ প্রদান করা অপরিহার্য।
  হেডারে একটি সংস্করণ নম্বর ছাড়া একটি বিন্যাস খারাপ!
  পৃষ্ঠার শিরোনামে একটি নির্দিষ্ট ম্যাজিক নম্বর (স্বাক্ষর) সহ একটি ক্ষেত্র যোগ করা যথেষ্ট, যা ব্যবহৃত ফর্ম্যাটের সংস্করণটি নির্দেশ করবে (আমি মনে করি না যে অনুশীলনে তাদের এক ডজনও থাকবে);
• রেকর্ডের জন্য একটি পরিবর্তনশীল-দৈর্ঘ্যের শিরোনাম ব্যবহার করুন (যার মধ্যে অনেকগুলি আছে), বেশিরভাগ ক্ষেত্রে এটি 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)

আমি ব্যাখ্যা করার চেষ্টা করেছি, আমি জানি না এটি কতটা স্পষ্টভাবে পরিণত হয়েছে:

হলুদ এখানে T ক্ষেত্র, সাদা S ক্ষেত্র, সবুজ L (বাইটে সংকুচিত ডেটার দৈর্ঘ্য), নীল সংকুচিত ডেটা, ফ্ল্যাশ মেমরিতে লেখা নয় এমন সংকুচিত ডেটার চূড়ান্ত বাইটগুলিকে লাল করে।

এইভাবে, আমরা একটি বাইটে সবচেয়ে সাধারণ দৈর্ঘ্যের (63+5 বাইট পর্যন্ত সংকুচিত আকারে) রেকর্ড হেডার লিখতে পারি।

প্রতিটি রেকর্ডের পরে, একটি CRC-32C চেকসাম সংরক্ষণ করা হয়, যেখানে পূর্ববর্তী চেকসামের উল্টানো মান প্রাথমিক মান (init) হিসাবে ব্যবহৃত হয়।

CRC-এর "সময়কাল" এর বৈশিষ্ট্য রয়েছে, নিম্নলিখিত সূত্রটি কাজ করে (প্রক্রিয়ায় প্লাস বা মাইনাস বিট বিপরীত): .
অর্থাৎ, প্রকৃতপক্ষে, আমরা এই পৃষ্ঠার হেডার এবং ডেটার পূর্ববর্তী সমস্ত বাইটের CRC গণনা করি।

সরাসরি চেকসাম অনুসরণ করা পরবর্তী রেকর্ডের শিরোনাম।

হেডারটি এমনভাবে ডিজাইন করা হয়েছে যে এর প্রথম বাইট সবসময় 0x00 এবং 0xff থেকে আলাদা হয় (যদি হেডারের প্রথম বাইটের পরিবর্তে আমরা 0xff এর সম্মুখীন হই, তাহলে এর মানে হল এটি একটি অব্যবহৃত এলাকা; 0x00 একটি ত্রুটির সংকেত দেয়)।

উদাহরণ অ্যালগরিদম

ফ্ল্যাশ মেমরি থেকে পড়া

যেকোনো রিডিং একটি চেকসাম চেকের সাথে আসে।
যদি চেকসাম মেলে না, সঠিক ডেটা পড়ার আশায় রিডিংটি কয়েকবার পুনরাবৃত্তি করা হয়।

(এটি বোঝা যায়, লিনাক্স নর ফ্ল্যাশ থেকে পড়া ক্যাশে করে না, পরীক্ষিত)

ফ্ল্যাশ মেমরিতে লিখুন

আমরা ডেটা রেকর্ড করি।
আসুন সেগুলো পড়ি।

যদি পঠিত ডেটা লিখিত ডেটার সাথে মেলে না, আমরা শূন্য দিয়ে এলাকাটি পূরণ করি এবং একটি ত্রুটি সংকেত করি।

অপারেশনের জন্য একটি নতুন মাইক্রোসার্কিট প্রস্তুত করা হচ্ছে

আরম্ভ করার জন্য, সংস্করণ 1 সহ একটি হেডার প্রথম (বা বরং শূন্য) পৃষ্ঠায় লেখা হয়।
এর পরে, প্রাথমিক প্রসঙ্গটি এই পৃষ্ঠায় লেখা হয় (মেশিনের UUID এবং ডিফল্ট সেটিংস রয়েছে)।

এটাই, ফ্ল্যাশ মেমরি ব্যবহারের জন্য প্রস্তুত।

মেশিন লোড হচ্ছে

লোড করার সময়, প্রতিটি পৃষ্ঠার প্রথম 8 বাইট (হেডার + CRC) পড়া হয়, একটি অজানা ম্যাজিক নম্বর বা একটি ভুল CRC সহ পৃষ্ঠাগুলি উপেক্ষা করা হয়।
"সঠিক" পৃষ্ঠাগুলি থেকে, সর্বাধিক সংস্করণ সহ পৃষ্ঠাগুলি নির্বাচন করা হয় এবং সর্বাধিক সংখ্যার পৃষ্ঠাটি তাদের থেকে নেওয়া হয়।
প্রথম রেকর্ড পড়া হয়, CRC এর সঠিকতা এবং "প্রসঙ্গ" পতাকার উপস্থিতি পরীক্ষা করা হয়। সবকিছু ঠিক থাকলে, এই পৃষ্ঠাটি বর্তমান হিসাবে বিবেচিত হবে। যদি না হয়, আমরা একটি "লাইভ" পৃষ্ঠা না পাওয়া পর্যন্ত আমরা আগেরটিতে ফিরে যাই।
এবং পাওয়া পৃষ্ঠায় আমরা সমস্ত রেকর্ড পড়ি, যেগুলি আমরা "প্রসঙ্গ" পতাকা দিয়ে ব্যবহার করি।
zlib অভিধানটি সংরক্ষণ করুন (এই পৃষ্ঠায় যোগ করার জন্য এটি প্রয়োজন হবে)।

এটিই, ডাউনলোড সম্পূর্ণ হয়েছে, প্রসঙ্গ পুনরুদ্ধার করা হয়েছে, আপনি কাজ করতে পারেন।

একটি জার্নাল এন্ট্রি যোগ করা হচ্ছে

আমরা Z_SYNC_FLUSH উল্লেখ করে সঠিক অভিধানের সাথে রেকর্ডটি সংকুচিত করি। আমরা দেখি সংকুচিত রেকর্ডটি বর্তমান পৃষ্ঠায় খাপ খায় কিনা।
যদি এটি উপযুক্ত না হয় (বা পৃষ্ঠায় CRC ত্রুটি ছিল), একটি নতুন পৃষ্ঠা শুরু করুন (নীচে দেখুন)।
আমরা রেকর্ড এবং সিআরসি লিখে রাখি। যদি একটি ত্রুটি ঘটে, একটি নতুন পৃষ্ঠা শুরু করুন.

নতুন পাতা

আমরা ন্যূনতম সংখ্যা সহ একটি বিনামূল্যের পৃষ্ঠা নির্বাচন করি (আমরা একটি বিনামূল্যের পৃষ্ঠাকে শিরোনামে একটি ভুল চেকসাম বা বর্তমানের চেয়ে কম সংস্করণ সহ একটি পৃষ্ঠা হিসাবে বিবেচনা করি)। যদি এই ধরনের কোনো পৃষ্ঠা না থাকে, তাহলে বর্তমানের সমান সংস্করণের ন্যূনতম সংখ্যার পৃষ্ঠাটি নির্বাচন করুন।
আমরা নির্বাচিত পৃষ্ঠা মুছে ফেলি। আমরা 0xff দিয়ে বিষয়বস্তু পরীক্ষা করি। কিছু ভুল হলে, পরবর্তী বিনামূল্যে পৃষ্ঠা নিন, ইত্যাদি।
আমরা মুছে ফেলা পৃষ্ঠায় একটি শিরোনাম লিখি, প্রথম এন্ট্রিটি প্রসঙ্গটির বর্তমান অবস্থা, পরবর্তীটি অলিখিত লগ এন্ট্রি (যদি একটি থাকে)।

ফর্ম্যাট প্রযোজ্যতা

আমার মতে, এটি নওর ফ্ল্যাশে যেকোন কম-বেশি সংকোচনযোগ্য তথ্য স্ট্রীম (প্লেন টেক্সট, জেএসএন, মেসেজপ্যাক, সিবিওআর, সম্ভবত প্রোটোবাফ) সংরক্ষণের জন্য একটি ভাল ফর্ম্যাট হিসাবে পরিণত হয়েছে।

অবশ্যই, ফর্ম্যাটটি SLC বা ফ্ল্যাশের জন্য "উপযুক্ত"।

এটি উচ্চ BER মিডিয়া যেমন NAND বা MLC NOR এর সাথে ব্যবহার করা উচিত নয় (এমন মেমরি কি বিক্রির জন্যও পাওয়া যায়? আমি শুধু সংশোধন কোডের কাজে এটি উল্লেখ দেখেছি).

তদুপরি, এটি তাদের নিজস্ব FTL আছে এমন ডিভাইসগুলির সাথে ব্যবহার করা উচিত নয়: USB ফ্ল্যাশ, SD, MicroSD, ইত্যাদি (এই ধরনের মেমরির জন্য আমি 512 বাইটের একটি পৃষ্ঠার আকার, প্রতিটি পৃষ্ঠার শুরুতে একটি স্বাক্ষর এবং অনন্য রেকর্ড নম্বর সহ একটি বিন্যাস তৈরি করেছি - কখনও কখনও সাধারণ অনুক্রমিক পাঠের মাধ্যমে একটি "গ্লিচড" ফ্ল্যাশ ড্রাইভ থেকে সমস্ত ডেটা পুনরুদ্ধার করা সম্ভব হয়েছিল).

কাজের উপর নির্ভর করে, বিন্যাসটি ফ্ল্যাশ ড্রাইভে 128Kbit (16Kb) থেকে 1Gbit (128MB) পরিবর্তন ছাড়াই ব্যবহার করা যেতে পারে। যদি ইচ্ছা হয়, আপনি এটি বড় চিপগুলিতে ব্যবহার করতে পারেন, তবে আপনাকে সম্ভবত পৃষ্ঠার আকার সামঞ্জস্য করতে হবে (কিন্তু এখানে ইতিমধ্যেই অর্থনৈতিক সম্ভাব্যতার প্রশ্ন উঠেছে; বড়-ভলিউম বা ফ্ল্যাশের দাম উৎসাহজনক নয়).

যদি কেউ ফরম্যাটটি আকর্ষণীয় মনে করে এবং এটি একটি খোলা প্রকল্পে ব্যবহার করতে চায়, লিখুন, আমি সময় খুঁজে বের করার চেষ্টা করব, কোডটি পোলিশ করব এবং গিথুবে পোস্ট করব।

উপসংহার

আপনি দেখতে পাচ্ছেন, শেষ পর্যন্ত বিন্যাসটি সরল হয়ে উঠল এবং এমনকি বিরক্তিকর.

একটি নিবন্ধে আমার দৃষ্টিভঙ্গির বিবর্তন প্রতিফলিত করা কঠিন, তবে আমাকে বিশ্বাস করুন: প্রাথমিকভাবে আমি এমন কিছু তৈরি করতে চেয়েছিলাম যা পরিশীলিত, অবিনশ্বর, এমনকি কাছাকাছি একটি পারমাণবিক বিস্ফোরণ থেকেও বেঁচে থাকতে সক্ষম। যাইহোক, কারণ (আমি আশা করি) এখনও জিতেছে এবং ধীরে ধীরে অগ্রাধিকারগুলি সরলতা এবং সংক্ষিপ্ততার দিকে স্থানান্তরিত হয়েছে।

এটা কি হতে পারে যে আমি ভুল ছিলাম? হ্যাঁ অবশ্যই. উদাহরণস্বরূপ, আমরা নিম্ন-মানের মাইক্রোসার্কিটের একটি ব্যাচ কিনেছি। অথবা অন্য কোন কারণে সরঞ্জাম নির্ভরযোগ্যতা প্রত্যাশা পূরণ করবে না.

এই জন্য আমার একটি পরিকল্পনা আছে? আমি মনে করি নিবন্ধটি পড়ার পরে আপনার কোন সন্দেহ নেই যে একটি পরিকল্পনা আছে। এবং এমনকি একা না.

একটু বেশি গুরুতর নোটে, ফরম্যাটটি একটি কাজের বিকল্প এবং "ট্রায়াল বেলুন" হিসাবে উভয়ই তৈরি করা হয়েছিল।

এই মুহূর্তে টেবিলের সবকিছু ঠিকঠাক কাজ করছে, আক্ষরিক অর্থে অন্য দিন সমাধানটি স্থাপন করা হবে (আন্দাজ) একশত ডিভাইসে, দেখা যাক "যুদ্ধ" অপারেশনে কী ঘটে (সৌভাগ্যবশত, আমি আশা করি বিন্যাসটি আপনাকে নির্ভরযোগ্যভাবে ব্যর্থতা সনাক্ত করতে দেয়; যাতে আপনি সম্পূর্ণ পরিসংখ্যান সংগ্রহ করতে পারেন)। কয়েক মাসের মধ্যে সিদ্ধান্তে আসা সম্ভব হবে (এবং যদি আপনি দুর্ভাগ্যবান হন, এমনকি আগে).

যদি, ব্যবহারের ফলাফলের উপর ভিত্তি করে, গুরুতর সমস্যাগুলি আবিষ্কৃত হয় এবং উন্নতির প্রয়োজন হয়, তবে আমি অবশ্যই এটি সম্পর্কে লিখব।

সাহিত্য

আমি ব্যবহৃত কাজের একটি দীর্ঘ ক্লান্তিকর তালিকা তৈরি করতে চাইনি; সর্বোপরি, প্রত্যেকের কাছেই Google আছে।

এখানে আমি অনুসন্ধানের একটি তালিকা ছেড়ে দেওয়ার সিদ্ধান্ত নিয়েছি যা আমার কাছে বিশেষভাবে আকর্ষণীয় বলে মনে হয়েছিল, কিন্তু ধীরে ধীরে তারা সরাসরি নিবন্ধের পাঠ্যে স্থানান্তরিত হয়েছে এবং একটি আইটেম তালিকায় রয়ে গেছে:

1. ইউটিলিটি infgen লেখক zlib থেকে. deflate/zlib/gzip আর্কাইভের বিষয়বস্তু স্পষ্টভাবে প্রদর্শন করতে পারে। যদি আপনাকে ডিফ্লেট (বা জিজিপ) বিন্যাসের অভ্যন্তরীণ কাঠামোর সাথে মোকাবিলা করতে হয় তবে আমি এটির সুপারিশ করছি।

উত্স: www.habr.com