စောပိုငျးကာလ

ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ဒီဇိုင်းဖြင့် ရောင်းချသည့်စက်များရှိသည်။ အတွင်းတွင် Raspberry Pi နှင့် သီးခြားဘုတ်တစ်ခုပေါ်တွင် ကြိုးအချို့ပါရှိသည်။ အကြွေစေ့လက်ခံသူ၊ ဘေလ်လက်ခံသူ၊ ဘဏ်ဂိတ်တစ်ခု ချိတ်ဆက်ထားသည်... အရာအားလုံးကို ကိုယ်တိုင်ရေးထားသော ပရိုဂရမ်ဖြင့် ထိန်းချုပ်ထားသည်။ အလုပ်၏သမိုင်းတစ်ခုလုံးကို flash drive (MicroSD) တွင် ဂျာနယ်တွင်ရေးထားပြီး ၎င်းကိုဒေတာဘေ့စ်တစ်ခုတွင်သိမ်းဆည်းထားသည့်ဆာဗာသို့အင်တာနက် (USB modem ကိုအသုံးပြု၍) မှတဆင့်ပေးပို့သည်။ အရောင်းအချက်အလက်ကို 1C တွင် တင်ထားပြီး၊ စောင့်ကြည့်ရန်အတွက် ရိုးရှင်းသော ဝဘ်အင်တာဖေ့စ်တစ်ခုလည်း ရှိပါသည်။

ဆိုလိုသည်မှာ၊ ဂျာနယ်သည် စာရင်းကိုင် (ဝင်ငွေ၊ အရောင်းစသည်) အတွက် အရေးကြီးသည် - စောင့်ကြည့်ခြင်း (ကျရှုံးမှု အမျိုးမျိုးနှင့် အခြားသော ပြင်းထန်သော အခြေအနေများ)၊ ဒါက ဒီစက်နဲ့ပတ်သက်တဲ့ အချက်အလက်အားလုံးလို့ ပြောလို့ရတယ်။

ပြဿနာ

Flash drives များသည် အလွန်ယုံကြည်စိတ်ချရသော စက်ပစ္စည်းများဖြစ်ကြောင်း သက်သေပြပါသည်။ မနာလိုဖွယ် မှန်မှန်ဖြင့် ဖြိုခွင်းကြသည်။ ၎င်းသည် စက်ရပ်နေချိန်နှင့် (အကြောင်းတစ်ခုခုကြောင့် မှတ်တမ်းကို အွန်လိုင်းသို့ မလွှဲပြောင်းနိုင်ခဲ့ပါက) ဒေတာ ဆုံးရှုံးသွားစေသည်။

၎င်းသည် flash drives များကိုအသုံးပြုခြင်း၏ပထမဆုံးအတွေ့အကြုံမဟုတ်သေးမီ၊ ဂျာနယ်ကို USB flash drive များတွင်သိမ်းဆည်းထားသည့်ကိရိယာတစ်ရာကျော်ရှိသည့်နောက်ထပ်ပရောဂျက်တစ်ခုရှိခဲ့သော်လည်း၊ ယုံကြည်စိတ်ချရမှုဆိုင်ရာပြဿနာများလည်းရှိခဲ့ပြီး တစ်ခါတစ်ရံတွင် တစ်လလျှင် မအောင်မြင်သောစက်ပစ္စည်းအရေအတွက်သည် ဆယ်ဂဏန်းအထိရှိခဲ့သည်။ SLC မမ်မိုရီပါသည့် အမှတ်တံဆိပ်ပါရှိသည့် တံဆိပ်များအပါအဝင် မတူညီသော flash drive များကို ကျွန်ုပ်တို့ စမ်းသပ်ခဲ့ပြီး အချို့သော မော်ဒယ်များသည် အခြားသူများထက် ပိုမိုစိတ်ချရသော်လည်း flash drive များကို အစားထိုးခြင်းသည် ပြဿနာကို ကြီးမားစွာ မဖြေရှင်းနိုင်ခဲ့ပါ။

သတိပေးခြင်း! အရှည်ကြီး! "ဘာကြောင့်လဲ" ကို စိတ်မဝင်စားရင် "ဘယ်လို" နဲ့သာ တည့်တည့်သွားနိုင်ပါတယ်။ အဆုံးသတ်မှာ ဆောင်းပါး။

ဆုံးဖြတ်ချက်

ပထမဆုံး သတိရမိတာကတော့ MicroSD ကို စွန့်လွှတ်ပြီး ဥပမာ၊ SSD တစ်ခုကို ထည့်သွင်းပြီး ၎င်းကနေ စတင်လိုက်ပါ။ သီအိုရီအရဖြစ်ကောင်းဖြစ်နိုင်သော်လည်း အတော်လေးစျေးကြီးပြီး ယုံကြည်စိတ်ချရခြင်းမရှိပါ (USB-SATA အဒက်တာတစ်ခုထပ်ထည့်ထားသည်၊ ဘတ်ဂျက် SSD များအတွက် ကျရှုံးမှုစာရင်းအင်းများမှာလည်း အားရစရာမရှိပါ)။

USB HDD သည် အထူးဆွဲဆောင်မှုရှိသော ဖြေရှင်းချက်တစ်ခုနှင့် မတူပေ။

ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ဤရွေးချယ်ခွင့်သို့ ရောက်လာသည်- MicroSD မှ boot ကို ထားခဲ့ပါ၊ သို့သော် ၎င်းတို့ကို ဖတ်ရန်-သပ်သပ်မုဒ်တွင် အသုံးပြုကာ အလုပ်မှတ်တမ်းကို သိမ်းဆည်းပါ (နှင့် သီးခြား ဟာ့ဒ်ဝဲ အစိတ်အပိုင်းတစ်ခု၏ အခြားသော အချက်အလက် - အမှတ်စဉ် နံပါတ်၊ အာရုံခံ ချိန်ညှိမှုများ စသည်ဖြင့်) အခြားတစ်နေရာတွင် ဖြစ်သည်။

Raspberry Pi အတွက် read-only FS ၏ ခေါင်းစဉ်ကို အတက်အဆင်း လေ့လာထားပြီးဖြစ်သည်၊ ဤဆောင်းပါးတွင် အကောင်အထည်ဖော်မှုအသေးစိတ်များကို ကျွန်ုပ်မစဉ်းစားပါ။ (ဒါပေမယ့် စိတ်ဝင်စားတယ်ဆိုရင်တော့ ဒီအကြောင်းအရာနဲ့ ပတ်သက်ပြီး ဆောင်းပါးတိုလေးတစ်ခု ရေးဖြစ်နိုင်ပါတယ်). သတိပြုစေလိုသည့် တစ်ခုတည်းသောအချက်မှာ ကိုယ်တွေ့ အတွေ့အကြုံအရရော ၎င်းကို အကောင်အထည်ဖော်ဖူးသူများ၏ သုံးသပ်ချက်များအရ ယုံကြည်စိတ်ချရမှုတွင် အမြတ်အစွန်းများ ရှိပါသည်။ ဟုတ်တယ်၊ ပြိုကွဲမှုတွေကို လုံးဝဖယ်ရှားပစ်ဖို့ မဖြစ်နိုင်ပေမယ့် သူတို့ရဲ့ အကြိမ်ရေကို သိသိသာသာ လျှော့ချဖို့ အတော်လေး ဖြစ်နိုင်တယ်။ ကတ်များသည် တစ်စုတစ်စည်းတည်းဖြစ်လာပြီး ဝန်ဆောင်မှုဝန်ထမ်းများအတွက် အစားထိုးမှုမှာ သိသာထင်ရှားစွာရိုးရှင်းစေသည်။

ဟာ့ဒ်ဝဲအစိတ်အပိုင်းတစ်ခု

Memory အမျိုးအစား - NOR Flash ရွေးချယ်မှုနှင့်ပတ်သက်၍ အထူးသံသယဖြစ်စရာမရှိပါ။
အငြင်းပွားမှုများ:

• ရိုးရှင်းသောချိတ်ဆက်မှု (များသောအားဖြင့်ကျွန်ုပ်တို့အသုံးပြုသောအတွေ့အကြုံရှိပြီးသား SPI ဘတ်စ်ကား၊ ထို့ကြောင့် hardware ပြဿနာများမျှော်လင့်မထားပါ)
• ရယ်စရာကောင်းသောစျေးနှုန်း;
• စံလည်ပတ်မှုပရိုတိုကော (အကောင်အထည်ဖော်မှုသည် kernel တွင်ရှိပြီးသား) Linuxသင်အလိုရှိပါက၊ ပြင်ပကုမ္ပဏီတစ်ခုကိုယူနိုင်သည်၊ ၎င်းတို့လည်းရှိနေနိုင်သည်၊ သို့မဟုတ် သင့်ကိုယ်ပိုင်ရေးသားနိုင်သည်၊ ကံကောင်းထောက်မစွာ၊ အရာအားလုံးသည် ရိုးရှင်းပါသည်)။
• ယုံကြည်စိတ်ချရမှုနှင့် အရင်းအမြစ်-
  ပုံမှန်ဒေတာစာရွက်မှ- ဒေတာကို အနှစ် 20 သိမ်းဆည်းထားပြီး ဘလောက်တစ်ခုစီအတွက် 100000 erase cycles;
  ပြင်ပအဖွဲ့အစည်းမှ အရင်းအမြစ်များမှ- အလွန်နိမ့်ကျသော BER၊ အမှားပြင်ဆင်မှုကုဒ်များကို သတ်မှတ်ဖော်ပြရန် မလိုအပ်ပါ။ (အချို့စာတမ်းများက ECC ကို NOR ဟုယူဆသော်လည်း အများအားဖြင့် ၎င်းတို့သည် MLC NOR ကိုဆိုလိုသည်၊ ဤသို့လည်း ဖြစ်တတ်သည်).

ပမာဏနှင့် အရင်းအမြစ်အတွက် လိုအပ်ချက်များကို ခန့်မှန်းကြည့်ကြပါစို့။

ဒေတာကို ရက်အတော်ကြာ သိမ်းဆည်းထားကြောင်း သေချာစေလိုပါသည်။ ချိတ်ဆက်မှုပြဿနာများရှိပါက အရောင်းမှတ်တမ်းမပျောက်စေရန် ၎င်းသည် လိုအပ်ပါသည်။ ဤကာလအတွက် ၅ ရက်ကို အာရုံစိုက်ပါမည်။ (စနေ၊ တနင်္ဂနွေနှင့် အားလပ်ရက်များကို ထည့်သွင်းစဉ်းစားခြင်း) ပြဿနာကိုဖြေရှင်းနိုင်ပါတယ်။

လက်ရှိတွင် ကျွန်ုပ်တို့တွင် တစ်နေ့လျှင် မှတ်တမ်း 100kb ခန့် (မှတ်တမ်း 3-4) ခန့်ရှိသည်၊ သို့သော် ဤကိန်းဂဏန်းသည် တဖြည်းဖြည်း ကြီးထွားလာသည် - အသေးစိတ်အချက်အလက်များ တိုးလာကာ ဖြစ်ရပ်အသစ်များကို ထပ်လောင်းပါသည်။ ထို့အပြင်၊ တစ်ခါတစ်ရံတွင် လှိုင်းများ တက်လာသည် (ဥပမာ အချို့သော အာရုံခံကိရိယာများသည် မှားယွင်းသော အပြုသဘောများဖြင့် စပမ်းပို့ခြင်း စတင်သည်)။ ကျွန်ုပ်တို့သည် တစ်နေ့လျှင် မီဂါဘိုက် 10 bytes မှတ်တမ်း 100 အတွက် တွက်ချက်ပါမည်။

စုစုပေါင်း၊ ဒေတာသန့်ရှင်းမှု (ကောင်းမွန်စွာချုံ့ထားသော) 5MB ရှိပါသည်။ အဲဒါအပြင်၊ (အကြမ်းဖျင်း ခန့်မှန်းချက်) ဝန်ဆောင်မှုဒေတာ 1MB ။

ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် compression ကိုအသုံးမပြုပါက 8 MB အတွက်ချစ်ပ်တစ်ခုလိုအပ်သည်၊ သို့မဟုတ်ကျွန်ုပ်တို့ပြုလုပ်ပါက 4 MB လိုအပ်သည်။ ဤမှတ်ဉာဏ်အမျိုးအစားအတွက် အလွန်လက်တွေ့ကျသော ကိန်းဂဏန်းများ။

အရင်းအမြစ်နှင့်ပတ်သက်ပြီး ကျွန်ုပ်တို့သည် မှတ်ဉာဏ်ကို 5 ရက်လျှင် တစ်ကြိမ်ထက် မကြာမကြာပြန်ရေးရန်စီစဉ်ထားပါက၊ ဝန်ဆောင်မှု 10 နှစ်နှင့်အထက် ကျွန်ုပ်တို့သည် ပြန်လည်ရေးသားခြင်းစက်ဝန်းတစ်ထောင်အောက် ရရှိမည်ဖြစ်သည်။
ထုတ်လုပ်သူသည် တစ်သိန်း ကတိပြုကြောင်း သတိပေးပါရစေ။

NOR vs NAND အကြောင်းအနည်းငယ်

သေချာပါတယ်၊ ဒီနေ့၊ NAND memory က ပိုလူကြိုက်များပါတယ်၊ ဒါပေမယ့် ဒီပရောဂျက်အတွက် ကျွန်တော်သုံးမှာမဟုတ်ပါဘူး- NAND၊ NOR နဲ့မတူဘဲ၊ အမှားပြင်ဆင်ခြင်းကုဒ်တွေ၊ မကောင်းတဲ့ဘလောက်ဇယား စတာတွေကို မဖြစ်မနေအသုံးပြုဖို့လိုအပ်ပါတယ်၊ NAND ချစ်ပ်တွေမှာ များသောအားဖြင့် ပင်နံပါတ်များစွာပါရှိပါတယ်။

NOR ၏ အားနည်းချက်များမှာ-

• သေးငယ်သော ထုထည် (ထို့ကြောင့် မီဂါဘိုက်တစ်ခုလျှင် မြင့်မားသောစျေးနှုန်း);
• လဲလှယ်နှုန်း နည်းပါးခြင်း (Serial interface ကို အများအားဖြင့် SPI သို့မဟုတ် I2C ကို အသုံးပြုထားခြင်းကြောင့်)။
• နှေးကွေးစွာ ဖျက်ခြင်း (ဘလောက်အရွယ်အစားပေါ်မူတည်၍ ၎င်းသည် တစ်စက္ကန့်၏အပိုင်းအစများမှ စက္ကန့်များစွာကြာသည်)။

ငါတို့အတွက် ဘာမှအရေးမကြီးဘူးထင်တယ်၊ ဒါကြောင့် ငါတို့ဆက်လုပ်တယ်။

အသေးစိတ်အချက်အလက်များကို သင်စိတ်ဝင်စားပါက၊ microcircuit တစ်ခုကို ရွေးချယ်ထားသည်။ 25df321a တွင် (သို့သော်၊ ၎င်းသည် မရှိမဖြစ်လိုအပ်သည်၊ pinout နှင့် command system အရ သဟဇာတဖြစ်သော စျေးကွက်တွင် analog အများအပြားရှိပါသည်။ ကျွန်ုပ်တို့သည် အခြားထုတ်လုပ်သူနှင့်/သို့မဟုတ် အခြား volume မှ microcircuit တစ်ခုကို တပ်ဆင်လိုပါက၊ ကုဒ်ကိုမပြောင်းလဲဘဲ အရာအားလုံးသည် အလုပ်ဖြစ်လိမ့်မည်).

ကျွန်တော် kernel ထဲမှာ built-in ပါတဲ့ဟာကိုသုံးပါတယ် Linux Raspberry မှာ Driver အတွက် device tree overlay support ကြောင့် အရာအားလုံးက အရမ်းရိုးရှင်းပါတယ် - compile လုပ်ထားတဲ့ overlay ကို /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

Raspberry Pi နှင့် microcircuit ချိတ်ဆက်မှုအကြောင်း ဖော်ပြချက်ကို ကျော်သွားပါမည်။ တစ်ဖက်တွင်၊ ကျွန်ုပ်သည် အီလက်ထရွန်နစ်ပစ္စည်းကျွမ်းကျင်သူမဟုတ်ပါ၊ အခြားတစ်ဖက်တွင်၊ ကျွန်ုပ်အတွက်ပင် အရာအားလုံးသည် အသေးအဖွဲဖြစ်သည်- microcircuit တွင် ကျွန်ုပ်တို့လိုအပ်သော မြေပြင်၊ ပါဝါ၊ SPI (CS, SI, SO, SCK) တွင် ပင်နံပါတ် 8 ခုသာရှိသည်။ အဆင့်များသည် Raspberry Pi နှင့် တိုက်ဆိုင်သည်၊ နောက်ထပ် ထွားကျိုင်းရန် မလိုအပ်ပါ - သတ်မှတ်ထားသော အဆက်အသွယ် 6 ခုကို ချိတ်ဆက်ပါ။

ပြဿနာကိုပုံဖော်ခြင်း

ထုံးစံအတိုင်း၊ ပြဿနာထုတ်ပြန်ချက်သည် အကြိမ်ကြိမ် ထပ်ခါထပ်ခါဖြစ်နေပြီး နောက်တစ်ခုအတွက် အချိန်ရောက်ပြီထင်ပါတယ်။ ဒါကြောင့် ရပ်လိုက်ကြရအောင်၊ ရေးပြီးသားတွေကို စုစည်းပြီး မှောင်ရိပ်ထဲမှာ ကျန်နေသေးတဲ့ အသေးစိတ်အချက်လေးတွေကို ရှင်းပြလိုက်ကြရအောင်။

ထို့ကြောင့်၊ မှတ်တမ်းကို SPI NOR Flash တွင် သိမ်းဆည်းရန် ဆုံးဖြတ်လိုက်ပါသည်။

မသိသူများအတွက် NOR Flash ဆိုတာဘာလဲ

၎င်းသည် သင်လုပ်ဆောင်မှု သုံးခုကို လုပ်ဆောင်နိုင်သည့် မတည်ငြိမ်သော မှတ်ဉာဏ်တစ်ခုဖြစ်သည်။

1. စာဖတ်ခြင်း -
   အသုံးအများဆုံးစာဖတ်ခြင်း- ကျွန်ုပ်တို့သည် လိပ်စာကို ကျော်ဖြတ်ပြီး ကျွန်ုပ်တို့ လိုအပ်သလောက် ဘိုက်များစွာကို ဖတ်သည်။
2. စံချိန်:
   NOR flash တွင်ရေးခြင်းသည် သာမန်တစ်ခုနှင့်တူသော်လည်း ထူးခြားချက်တစ်ခုရှိသည်- သင်သည် 1 မှ 0 သို့ပြောင်းနိုင်သော်လည်း အပြန်အလှန်မပြောင်းပါ။ ဥပမာအားဖြင့်၊ အကယ်၍ ကျွန်ုပ်တို့တွင် 0x55 ကို memory cell တွင် 0x0f ရေးပြီးပါက၊ 0x05 ကို ထိုနေရာတွင် သိမ်းဆည်းထားပြီးဖြစ်သည်။ (အောက်ပါဇယားကိုကြည့်ပါ);
3. ဖျက်ရန်-
   ဟုတ်ပါတယ်၊ ကျွန်ုပ်တို့သည် ဆန့်ကျင်ဘက်လုပ်ဆောင်ချက်ကို လုပ်ဆောင်နိုင်ရန်လိုအပ်သည် - 0 မှ 1 ကိုပြောင်းပါ၊ ဤသည်မှာ ဖျက်ခြင်းလုပ်ဆောင်ချက်အတွက်ဖြစ်သည်။ ပထမနှစ်ခုနှင့်မတူဘဲ၊ ၎င်းသည် bytes ပေါ်တွင်မဟုတ်ဘဲ blocks များတွင်အလုပ်လုပ်သည် (ရွေးချယ်ထားသောချပ်စ်ရှိအနည်းဆုံးဖျက်ပစ်သည့်ပိတ်ဆို့သည် 4 KB)။ Erase သည် block တစ်ခုလုံးကို ပျက်စီးစေပြီး ၎င်းသည် 0 မှ 1 ကိုပြောင်းရန် တစ်ခုတည်းသောနည်းလမ်းဖြစ်သည်။ ထို့ကြောင့် flash memory နှင့်အလုပ်လုပ်သောအခါ၊ မကြာခဏ data structures များကို erase block boundary သို့ချိန်ညှိရန် လိုအပ်ပါသည်။
   NOR Flash သို့ စာရေးနေသည်

ဒွိဒေတာ

ကဖြစ်
01010101

မှတ်တမ်းတင်ထားသည်။
00001111

ဖြစ်လာသည်
00000101

မှတ်တမ်းကိုယ်တိုင်သည် ပြောင်းလဲနိုင်သော အရှည်မှတ်တမ်းများ ၏ အတွဲတစ်ခုဖြစ်သည်။ ပုံမှန်မှတ်တမ်းတစ်ခုသည် 30 bytes ခန့်ရှည်သည် (တစ်ခါတစ်ရံမှတ်တမ်းများသည် ကီလိုဘိုက်များစွာရှည်သော်လည်း)။ ဤကိစ္စတွင် ကျွန်ုပ်တို့သည် ၎င်းတို့နှင့်အတူ ဘိုက်အစုတစ်ခုအဖြစ်သာ လုပ်ဆောင်သော်လည်း သင်စိတ်ဝင်စားပါက မှတ်တမ်းများအတွင်း CBOR ကို အသုံးပြုပါသည်။

မှတ်တမ်းအပြင်၊ အပ်ဒိတ်လုပ်ထားခြင်းမရှိသော၊ အချို့သော "ဆက်တင်" အချက်အလက်အချို့ကို သိမ်းဆည်းရန် လိုအပ်သည်- အချို့သောစက်ပစ္စည်း ID၊ အာရုံခံချိန်ညှိမှုများ၊ "စက်ပစ္စည်းကို ယာယီပိတ်ထားသည်" အလံ၊ စသည်တို့ဖြစ်သည်။
ဤအချက်အလက်သည် CBOR တွင်လည်း သိမ်းဆည်းထားသည့် သော့တန်ဖိုးမှတ်တမ်းများ အစုအဝေးတစ်ခုဖြစ်သည်။ ကျွန်ုပ်တို့တွင် ဤအချက်အလက် အများအပြားမရှိပါ (အနည်းဆုံး ကီလိုဘိုက်အနည်းငယ်) ရှိပြီး ၎င်းကို မကြာခဏ အပ်ဒိတ်လုပ်ပါသည်။
နောင်တွင် ၎င်းကို ဆက်စပ်မှုဟု ခေါ်ပါမည်။

ဤဆောင်းပါးကို မည်သို့စတင်ခဲ့သည်ကို သတိရပါက၊ ယုံကြည်စိတ်ချရသော ဒေတာသိမ်းဆည်းမှုသေချာစေရန် အလွန်အရေးကြီးပြီး ဖြစ်နိုင်ပါက ဟာ့ဒ်ဝဲချို့ယွင်းချက်/ဒေတာယိုယွင်းမှုဖြစ်ပွားသည့်အချိန်တွင်ပင် ဖြစ်နိုင်ပါက အနှောက်အယှက်ကင်းစွာ လည်ပတ်နိုင်မည်ဖြစ်သည်။

မည်သည့်ပြဿနာများ၏ အရင်းအမြစ်များကို ထည့်သွင်းစဉ်းစားနိုင်သနည်း။

• ရေး/ဖျက်ခြင်း လုပ်ဆောင်ချက်များအတွင်း ပါဝါပြတ်တောက်ခြင်း။ ၎င်းသည် "တကောင့်ကို အကာအကွယ်မရှိသော" အမျိုးအစားမှဖြစ်သည်။
  အချက်အလက်တွေကနေ ဆွေးနွေးချက်များ stackexchange တွင်- flash ဖြင့်အလုပ်လုပ်နေစဉ်ပါဝါပိတ်ထားသောအခါ၊ ဖျက်ပစ်ခြင်း (၁) ခုနှင့်ရေးရန် (သတ်မှတ်ထားသည့် 1) သည် သတ်မှတ်မထားသောအပြုအမူဆီသို့ ဦးတည်သည်- ဒေတာကိုရေးသားနိုင်သည်၊ တစ်စိတ်တစ်ပိုင်းရေးသားနိုင်သည် (ဆိုပါစို့၊ ကျွန်ုပ်တို့သည် 0 bytes/10 bits ကို လွှဲပြောင်းပေးသော်လည်း 80 bits သာရေးနိုင်သည်)၊ အချို့သောဘစ်များသည် “reading 45 သို့မဟုတ် အလယ်အလတ်” အနေအထားတွင်အဆုံးသတ်သွားခြင်းလည်း ဖြစ်နိုင်သည်။
• flash memory တွင် အမှားအယွင်းများ ရှိနေသည်။
  BER သည် အလွန်နည်းသော်လည်း သုညနှင့် မညီမျှနိုင်ပါ။
• ဘတ်စ်ကား အမှားများ
  SPI မှတစ်ဆင့် ပေးပို့သော ဒေတာကို မည်သည့်နည်းဖြင့်မျှ အကာအကွယ် မပေးနိုင်ပါ။ တစ်ခုတည်းသောဘစ်အမှားများနှင့် ထပ်တူပြုခြင်းအမှားများ - ဘစ်များဆုံးရှုံးမှု သို့မဟုတ် ထည့်သွင်းခြင်း (ကြီးမားသောဒေတာပုံပျက်ခြင်းကိုဖြစ်စေသော) ကောင်းစွာဖြစ်ပေါ်နိုင်သည်။
• အခြားအမှားများ/ချို့ယွင်းချက်များ
  ကုဒ်အမှားများ၊ Raspberry ချို့ယွင်းချက်များ၊ ဂြိုလ်သားဝင်ရောက်စွက်ဖက်မှု...

ယုံကြည်စိတ်ချရမှု ရှိစေရန်အတွက် ကျွန်ုပ်၏ထင်မြင်ယူဆချက်အရ ဖြည့်ဆည်းပေးရမည့် လိုအပ်ချက်များကို ရေးဆွဲထားပါသည်။

• မှတ်တမ်းများကို flash memory တွင်ချက်ချင်းရေးသားရမည်ဖြစ်ပြီး၊ နှောင့်နှေးသောအရေးအသားကိုထည့်သွင်းစဉ်းစားမည်မဟုတ်ပါ။ - အမှားအယွင်းတစ်ခုဖြစ်ပေါ်ပါက၊ ၎င်းကိုရှာဖွေတွေ့ရှိပြီး တတ်နိုင်သမျှ စောစီးစွာလုပ်ဆောင်ရပါမည်။ - ဖြစ်နိုင်လျှင် စနစ်သည် အမှားများမှ ပြန်လည်ကောင်းမွန်ရမည်။
  (“မဖြစ်သင့်ဘူး” ဆိုတဲ့ ဘဝထဲက ဥပမာတစ်ခု၊ လူတိုင်းကြုံဖူးကြမယ်ထင်ပါတယ်- အရေးပေါ်ပြန်ဖွင့်ပြီးနောက်၊ ဖိုင်စနစ်က “ပျက်” ပြီး လည်ပတ်မှုစနစ်က boot မတက်ပါဘူး)

စိတ်ကူးတွေ၊ ချဉ်းကပ်မှုတွေ၊ အတွေးတွေ

ဒီပြဿနာကို စပြီးတွေးတဲ့အခါ၊ ဥပမာ- ခေါင်းထဲမှာ အတွေးတွေ ပေါ်လာတယ်။

• ဒေတာချုံ့ကိုအသုံးပြု;
• မှတ်တမ်းတစ်ခုတွင် အမှားအယွင်းတစ်ခုရှိလျှင် ကျန်ကို ပြဿနာမရှိဘဲ ဖတ်ရှုနိုင်စေရန် မှတ်တမ်းခေါင်းစီးများကို သီးသန့်သိမ်းဆည်းခြင်းကဲ့သို့သော လိမ္မာပါးနပ်သော ဒေတာဖွဲ့စည်းပုံများကို အသုံးပြုပါ။
• ပါဝါပိတ်သည့်အခါ ရေးခြင်းပြီးဆုံးမှုကို ထိန်းချုပ်ရန် ဘစ်အကွက်များကို အသုံးပြုပါ။
• အရာအားလုံးနှင့်လူတိုင်းအတွက် checksum များကိုသိမ်းဆည်းပါ။
• error-correcting coding ပုံစံအချို့ကို အသုံးပြုပါ။

ဤအယူအဆအချို့ကို အသုံးပြုခဲ့ပြီး အချို့မှာ စွန့်ပစ်ခံခဲ့ရသည်။ အဲဒါတွေကို စနစ်တကျ ဖြတ်သန်းကြရအောင်။

ဒေတာကိုချုံ့

မှတ်တမ်းထဲတွင် ကျွန်ုပ်တို့မှတ်တမ်းတင်ထားသော အဖြစ်အပျက်များသည် အတော်လေးတူညီပြီး ထပ်ခါတလဲလဲဖြစ်နိုင်သည် (“၅ ရူဘယ်ဒင်္ဂါးပြား”၊ “ပြောင်းလဲမှုခလုတ်ကိုနှိပ်လိုက်သည်”၊ …)။ ထို့ကြောင့် compression သည် အတော်လေး ထိရောက်သင့်သည်။

ဖိသိပ်မှု၏အပေါ်ယံမှာ အရေးမပါပါ (ကျွန်ုပ်တို့၏ပရိုဆက်ဆာသည် အလွန်အစွမ်းထက်ပါသည်၊ ပထမ Pi တွင် အကြိမ်ရေ 700 MHz ရှိသည့် core တစ်ခုရှိသည်၊ လက်ရှိမော်ဒယ်များတွင် ကြိမ်နှုန်းတစ်ဂစ်ဂါဟတ်ထက်ကျော်သော cores အများအပြားရှိသည်)၊ သိုလှောင်မှုနှင့်အတူ ဖလှယ်မှုအမြန်နှုန်းမှာ နိမ့်သည် (တစ်စက္ကန့်လျှင် မီဂါဘိုက်များစွာ) ၊ မှတ်တမ်းများ၏အရွယ်အစားသည် သေးငယ်သည်။ ယေဘုယျအားဖြင့်၊ compression သည် စွမ်းဆောင်ရည်အပေါ် အကျိုးသက်ရောက်ပါက၊ ၎င်းသည် အပြုသဘောသာဖြစ်သည်။ (လုံးဝ အပြစ်တင်ဝေဖန်စရာ မလိုပါဘူး)ထို့အပြင်၊ ကျွန်ုပ်တို့တွင် တကယ့် embedded တစ်ခု မရှိဘဲ ပုံမှန်တစ်ခုသာ ရှိပါသည်။ Linux — ဒါကြောင့် အကောင်အထည်ဖော်ဖို့ အားထုတ်မှု အများကြီး မလိုအပ်ပါဘူး (library ကို ချိတ်ဆက်ပြီး ၎င်းမှ function အနည်းငယ်ကို အသုံးပြုရုံနဲ့ လုံလောက်ပါတယ်)။

အလုပ်လုပ်သည့်စက်ပစ္စည်းမှ မှတ်တမ်းအပိုင်းအစ (1.7 MB၊ 70 မှတ်တမ်းများ) ကို ယူဆောင်ပြီး ကွန်ပျူတာပေါ်ရှိ gzip, lz4, lzop, bzip2, xz, zstd ကို အသုံးပြု၍ ကွန်ပြူတာတွင် ရရှိနိုင်သော compressibility ရှိမရှိကို ဦးစွာစစ်ဆေးခဲ့သည်။

• gzip၊ xz၊ zstd သည် အလားတူရလဒ်များ (40Kb) ကို ပြသခဲ့သည်။
  ဖက်ရှင်အကျဆုံး xz သည် ဤနေရာတွင် gzip သို့မဟုတ် zstd အဆင့်တွင် ပြသခဲ့ခြင်းကြောင့် အံ့သြမိပါသည်။
• ပုံသေဆက်တင်များဖြင့် lzip သည် အနည်းငယ်ပိုဆိုးသော ရလဒ်များကိုပေးသည်။
• lz4 နှင့် lzop သည် အလွန်ကောင်းမွန်သော ရလဒ်များကို မပြသခဲ့ပါ (150Kb);
• bzip2 သည် အံ့သြဖွယ်ကောင်းသော ရလဒ်များ (18Kb) ကို ပြသခဲ့သည်။

ဒါကြောင့် data တွေကို compresses အရမ်းကောင်းပါတယ်။
ဒါကြောင့် (ပြင်းထန်တဲ့ ချို့ယွင်းချက်တွေကို ရှာမတွေ့ရင်) ဖိသိပ်မှု ရှိပါလိမ့်မယ်။ တူညီသော flash drive တွင်ဒေတာများပိုမိုရရှိသောကြောင့်ဖြစ်သည်။

အားနည်းချက်တွေကို စဉ်းစားကြည့်ရအောင်။

ပထမပြဿနာ- မှတ်တမ်းတစ်ခုစီသည် flash သို့ ချက်ချင်းသွားသင့်သည်ဟု ကျွန်ုပ်တို့ သဘောတူထားပြီးဖြစ်သည်။ အများအားဖြင့်၊ archiver သည် output သို့ စာရေးရန် အချိန်ရောက်ပြီဟု ဆုံးဖြတ်သည်အထိ input stream မှ အချက်အလက်များကို စုဆောင်းပါသည်။ ချုံ့ထားသောဒေတာဘလောက်တစ်ခုကို ချက်ချင်းရယူပြီး မတည်ငြိမ်သောမှတ်ဉာဏ်တွင် သိမ်းဆည်းရန်လိုအပ်ပါသည်။

နည်းလမ်းသုံးမျိုး မြင်ပါတယ်

1. အထက်ဖော်ပြပါ algorithms များအစား အဘိဓာန်ချုံ့မှုကို အသုံးပြု၍ မှတ်တမ်းတစ်ခုစီကို ချုံ့ပါ။
   ၎င်းသည် လုံးဝအလုပ်လုပ်နိုင်သော ရွေးချယ်မှုတစ်ခုဖြစ်သော်လည်း ကျွန်ုပ်မကြိုက်ပါ။ ပိုမိုသင့်လျော်သော ချုံ့မှုအဆင့်ကို သေချာစေရန်၊ အဘိဓာန်ကို သီးခြားဒေတာအတွက် "အံဝင်ခွင်ကျ" ဖြစ်ရပါမည်။ မည်သည့်ပြောင်းလဲမှုမဆို compression အဆင့်ကို ဆိုးရွားစွာကျဆင်းစေပါသည်။ ဟုတ်ကဲ့၊ အဘိဓာန်ဗားရှင်းအသစ်ကို ဖန်တီးခြင်းဖြင့် ပြဿနာကို ဖြေရှင်းနိုင်သည်၊ သို့သော် ၎င်းသည် ခေါင်းကိုက်ခြင်းဖြစ်သည်- ကျွန်ုပ်တို့သည် အဘိဓာန်ဗားရှင်းအားလုံးကို သိမ်းဆည်းထားရန် လိုအပ်ပါသည်။ ထည့်သွင်းမှုတစ်ခုစီတွင်၊ ၎င်းကို ချုံ့ထားသည့် အဘိဓာန်၏ ဗားရှင်းကို ညွှန်ပြရန် လိုအပ်ပါသည်။...
2. "ဂန္ထဝင်" အယ်လဂိုရီသမ်များကို အသုံးပြု၍ မှတ်တမ်းတစ်ခုစီကို ဖိသိပ်ထားသော်လည်း အခြားသူများနှင့် သီးခြားခွဲမထားပါ။
   ထည့်သွင်းစဉ်းစားထားသည့် ဖိသိပ်မှု အယ်လဂိုရီသမ်များသည် ဤအရွယ်အစား (ဘိုက်ဆယ်ဂဏန်း) ၏ မှတ်တမ်းများနှင့် အလုပ်လုပ်ရန် ဒီဇိုင်းထုတ်ထားခြင်း မဟုတ်ဘဲ၊ ဖိသိပ်မှုအချိုးသည် 1 ထက် သိသိသာသာ လျော့နည်းမည် (ဆိုလိုသည်မှာ ချုံ့မှုအစား ဒေတာပမာဏ တိုးလာသည်)။
3. ဝင်ရောက်မှုတိုင်းပြီးနောက် FLUSH ပြုလုပ်ပါ။
   Compression library အများအပြားသည် FLUSH ကို ပံ့ပိုးပေးသည်။ ဤသည်မှာ ချုံ့ခြင်းလုပ်ငန်းစဉ်အတွက် ကန့်သတ်ချက်တစ်ခု (သို့မဟုတ်) မှတ်တမ်းတစ်ခုအား လက်ခံရရှိသောအခါတွင် ၎င်းသည် ဖိုင်ကိုချုံ့ထားသောစီးကြောင်းပုံစံဖြင့် ပြန်လည်ရယူပြီးနောက် ၎င်းသည် ၎င်း၏အခြေခံတွင် ပြန်လည်ရယူရန် ဖြစ်နိုင်သည်။ အားလုံး လက်ခံရရှိပြီးသော ဒေတာများကို ချုံ့မထားပါ။ ဒီ analog sync ဖိုင်စနစ်များတွင် သို့မဟုတ် commit sql တွင်
   အရေးကြီးတာက နောက်ဆက်တွဲ compression လုပ်ဆောင်ချက်တွေက စုဆောင်းထားတဲ့ အဘိဓာန်ကို သုံးနိုင်မှာဖြစ်ပြီး compression ratio က အရင်ဗားရှင်းမှာလောက် ထိခိုက်မှာ မဟုတ်ပါဘူး။

တတိယရွေးချယ်မှုကို ငါရွေးချယ်ခဲ့တာ ထင်ရှားတယ်လို့ ငါထင်တယ်၊ အဲဒါကို ပိုပြီးအသေးစိတ်ကြည့်ရအောင်။

တွေ့တယ်။ ဆောင်းပါးကောင်း zlib တွင် FLUSH အကြောင်း။

ဆောင်းပါးကိုအခြေခံ၍ ဒူးဆစ်စမ်းသပ်မှုတစ်ခုပြုလုပ်ခဲ့ပြီး စာမျက်နှာအရွယ်အစား 70 KB ရှိသော စက်ပစ္စည်းတစ်ခုမှ မှတ်တမ်းဝင်ရောက်မှု 60 ကို ရယူခဲ့သည်။ (နောက်မှ စာမျက်နှာအရွယ်အစားကို ပြန်လာခဲ့ပါမယ်) လက်ခံရရှိသည်-

ကနဦးဒေတာ
ဖိသိပ်မှု gzip -9 (FLUSH မပါဘဲ)
Z_PARTIAL_FLUSH ဖြင့် zlib
Z_SYNC_FLUSH ဖြင့် zlib

ထုထည်၊ Kb
1692
40
352
604

ပထမတစ်ချက်တွင်၊ FLUSH ၏ကုန်ကျစရိတ်သည် အလွန်မြင့်မားသော်လည်း အမှန်တကယ်တွင် ကျွန်ုပ်တို့တွင် လုံးဝမချုံ့ရန် သို့မဟုတ် FLUSH ဖြင့် (အတော်လေးထိထိရောက်ရောက်) ချုံ့ရန် ရွေးချယ်မှုမှာ ညံ့ဖျင်းပါသည်။ ကျွန်ုပ်တို့တွင် မှတ်တမ်းပေါင်း 70 ရှိသည်ကို မမေ့သင့်ပါ၊ Z_PARTIAL_FLUSH မှ မိတ်ဆက်သည့် ထပ်လောင်းပမာဏသည် မှတ်တမ်းတစ်ခုလျှင် 4-5 bytes သာရှိသည်။ ပြီးတော့ compression ratio က 5:1 နီးပါး ဖြစ်သွားတယ်၊ အဲဒါက အရမ်းကောင်းတဲ့ ရလဒ်ထက် ပိုပါတယ်။

၎င်းသည် အံ့သြစရာဟု ထင်ရသော်လည်း Z_SYNC_FLUSH သည် အမှန်တကယ် FLUSH ပြုလုပ်ရန် ပိုမိုထိရောက်သော နည်းလမ်းဖြစ်သည်။

Z_SYNC_FLUSH ကိုအသုံးပြုပါက မှတ်တမ်းတစ်ခုစီ၏ နောက်ဆုံး 4 bytes သည် အမြဲတမ်း 0x00, 0x00, 0xff, 0xff ဖြစ်လိမ့်မည်။ ၎င်းတို့ကို သိပါက ၎င်းတို့ကို သိမ်းဆည်းနိုင်မည် မဟုတ်သောကြောင့် နောက်ဆုံးအရွယ်အစားမှာ 324 KB သာဖြစ်သည်။

ကျွန်တော် လင့်ခ်ချိတ်ထားတဲ့ ဆောင်းပါးမှာ ရှင်းပြချက် ရှိပါတယ်-

အချည်းနှီးသော အကြောင်းအရာများပါရှိသော အမျိုးအစား 0 ပိတ်ဆို့မှုအသစ်ကို ပေါင်းထည့်ထားသည်။

အချည်းနှီးသော အကြောင်းအရာများပါရှိသော အမျိုးအစား 0 ပိတ်ဆို့ခြင်းတွင်-

• သုံးဘစ်ပိတ်ဆို့ခေါင်းစီး;
• byte ချိန်ညှိမှုအောင်မြင်ရန် 0 မှ 7 bits သည် သုညနှင့်ညီသည်။
• four-byte sequence 00 00 FF FF ။

သင်အလွယ်တကူမြင်နိုင်သည်အတိုင်း၊ ဤ 4 bytes မတိုင်မီနောက်ဆုံးအကွက်တွင် 3 မှ 10 ဘစ်များမှ သုညအထိရှိသည်။ သို့သော်၊ လက်တွေ့တွင် သုညဘစ် ၁၀ ခုထက်မနည်းရှိကြောင်း ပြသထားသည်။

ဤကဲ့သို့သော ဒေတာအတိုအတုံးများကို အများအားဖြင့် (အမြဲတမ်း?) အမျိုးအစား 1 (ပုံသေဘစ်) ဖြင့် 7 သုညဘစ်ဖြင့် အဆုံးသတ်သော ဘလောက်တစ်ခုကို အသုံးပြု၍ ကုဒ်လုပ်ထားသောကြောင့် ကျွန်ုပ်တို့သည် အာမခံထားသော သုညဘစ် 10-17 ကိုရနိုင်သည် (ကျန်သည် 50%) ခန့် ဖြစ်နိုင်ခြေရှိသော သုညဖြစ်ပါမည်။

ထို့ကြောင့်၊ 100x0၊ 00x0၊ 00xff၊ 0xff မတိုင်မီ အမှုများ၏ 0% တွင် စမ်းသပ်ဒေတာတွင် သုညဘိုက်တစ်ခု ရှိပြီး သုံးပုံတစ်ပုံကျော်တွင် သုညဘိုက်နှစ်ခုရှိသည် (အဓိကအချက်ကတော့ ကျွန်တော် binary CBOR ကိုသုံးတာဖြစ်နိုင်တယ်၊ စာသား JSON ကိုသုံးရင်၊ အမျိုးအစား 2 - dynamic blocks တွေရဲ့ blocks တွေကို ပိုပြီးကြုံတွေ့ရတတ်ပါတယ်၊ 0x00, 0x00, 0xff, 0xff မတိုင်ခင် နောက်ထပ် zero bytes မပါဘဲ blocks တွေနဲ့ ကြုံတွေ့ရပါလိမ့်မယ်).

စုစုပေါင်း၊ ရရှိနိုင်သော စမ်းသပ်မှုဒေတာကို အသုံးပြု၍ ချုံ့ထားသောဒေတာ၏ 250 KB အောက်နှင့် အံဝင်ခွင်ကျဖြစ်နိုင်သည်။

အတုံးအခဲများဖြင့် ခြွေတာနိုင်သည်- ယခု ကျွန်ုပ်တို့သည် ဘလောက်တစ်ခု၏အဆုံးတွင် သုညဘစ်အနည်းငယ်ပါဝင်မှုကို လျစ်လျူရှုထားပြီး ဘလောက်တစ်ခု၏အစတွင် အနည်းငယ်သောဘစ်များသည်လည်း ပြောင်းလဲမည်မဟုတ်ပါ...
သို့သော် ဤနေရာတွင် ကျွန်ုပ်သည် ရပ်တန့်ရန် စိတ်အားထက်သန်သော ဆုံးဖြတ်ချက်တစ်ခုကို ချလိုက်သည်၊ မဟုတ်ပါက ဤနှုန်းဖြင့် ကျွန်ုပ်၏ကိုယ်ပိုင် archiver ကို တီထွင်နိုင်မည်ဖြစ်သည်။

စုစုပေါင်း၊ ကျွန်ုပ်သည် ကျွန်ုပ်၏စမ်းသပ်မှုဒေတာမှ မှတ်တမ်းတစ်ခုလျှင် 3-4 bytes ရခဲ့ပြီး၊ ချုံ့မှုအချိုးသည် 6:1 ထက်ပိုပါသည်။ ရိုးရိုးသားသားပြောရရင် ဒီလိုရလဒ်မျိုးကို ကျွန်တော် မမျှော်လင့်ထားပါဘူး၊ ကျွန်တော့်အမြင်အရ၊ 2:1 ထက် ပိုကောင်းတဲ့ အရာက compression ကိုအသုံးပြုခြင်းက တရားမျှတတဲ့ရလဒ်ဖြစ်နေပါပြီ။

အရာအားလုံးသည် ကောင်းမွန်သော်လည်း zlib (deflate) သည် ရှေးရိုးဆန်သော၊ ကောင်းမွန်ထိုက်တန်ပြီး အတန်ငယ် ခေတ်မီသော ဖိသိပ်မှုဆိုင်ရာ အယ်လဂိုရီသမ်တစ်ခု ဖြစ်နေဆဲဖြစ်သည်။ ချုံ့မထားသော ဒေတာစီးကြောင်း၏ နောက်ဆုံး 32K ကို အဘိဓာန်တစ်ခုအဖြစ် ယနေ့အသုံးပြုနေသည်ဟူသောအချက်ကို ယနေ့ခေတ်တွင် ထူးဆန်းပုံပေါ်သည် (ဆိုလိုသည်မှာ၊ အချို့သောဒေတာဘလောက်သည် လွန်ခဲ့သော 40K တွင်ရှိခဲ့သည့် input stream နှင့် အလွန်ဆင်တူပါက၊ ၎င်းသည် ထပ်မံ၍ သိမ်းဆည်းခြင်းစတင်မည်ဖြစ်ပြီး ယခင်ထည့်သွင်းမှုကို ရည်ညွှန်းမည်မဟုတ်ပါ)။ ခေတ်ဆန်သော ခေတ်မီ archivers များတွင် အဘိဓာန်အရွယ်အစားကို ကီလိုဘိုက်မဟုတ်ဘဲ မီဂါဘိုက်ဖြင့် တိုင်းတာလေ့ရှိသည်။

ထို့ကြောင့်၊ ကျွန်ုပ်တို့၏ မော်ကွန်းတိုက်များ၏ အသေးစားသုတေသနကို ဆက်လက်လုပ်ဆောင်ကြပါစို့။

ထို့နောက် bzip2 ကို စမ်းသပ်ခဲ့သည် (FLUSH မပါပဲ၊ 100:1 နီးပါး အံ့သြဖွယ် ဖိသိပ်မှုအချိုးကို ပြသခဲ့သည်ကို သတိရပါ)။ Alas၊ FLUSH ဖြင့် ၎င်းသည် သူ့ကိုယ်သူ အလွန်ညံ့ဖျင်းကြောင်းပြသခဲ့ပြီး၊ ချုံ့ထားသောဒေတာ၏အရွယ်အစားသည် ချုံ့မထားသောဖိုင်ထက် ပိုကြီးသည်။

ကျရှုံးရတဲ့ အကြောင်းရင်းနဲ့ ပတ်သက်ပြီး ကျွန်တော့်ရဲ့ ခန့်မှန်းချက်

Libbz2 သည် အဘိဓာန်ကို flush လုပ်ထားပုံရသည် (zlib တွင် Z_FULL_FLUSH နှင့် တူညီသော) flush option တစ်ခုသာ ပေးစွမ်းသောကြောင့် ၎င်းနောက်မှ ထိရောက်သော compression အကြောင်းကို ပြောစရာအကြောင်းမရှိပါ။

နောက်ဆုံးစမ်းသပ်ရမည့်အရာမှာ zstd ဖြစ်သည်။ ကန့်သတ်ချက်များအပေါ်မူတည်၍ ၎င်းသည် gzip အဆင့်တွင်ဖြစ်စေ ဖိသိပ်ထားသော်လည်း ပိုမိုမြန်ဆန်သည် သို့မဟုတ် gzip ထက် ပိုကောင်းသည်။

ကံမကောင်းစွာဖြင့်၊ FLUSH ဖြင့်၎င်းသည် "သိပ်မကောင်းပါ" ဟုလည်းပြသခဲ့သည်- compressed data ၏အရွယ်အစားသည် 700 KB ခန့်ဖြစ်သည်။

Я မေးခွန်းတစ်ခုမေးတယ်။ github ရှိ ပရောဂျက်စာမျက်နှာတွင်၊ compressed data ဘလောက်တစ်ခုစီအတွက် ဝန်ဆောင်မှုဒေတာ 10 bytes အထိ ရေတွက်ရကျိုးနပ်ကြောင်း အဖြေရခဲ့ပြီး၊ ရရှိသောရလဒ်များနှင့် နီးစပ်သောကြောင့် မကျေမနပ်ဖြစ်ကာ လိုက်လျောညီထွေမဖြစ်နိုင်ပါ။

ဤအချိန်တွင် archivers များနှင့် စမ်းသပ်ခြင်းကို ရပ်ရန် ဆုံးဖြတ်ခဲ့သည် (xz, lzip, lzo, lz4 သည် FLUSH မပါဘဲ စမ်းသပ်သည့်အဆင့်တွင် ၎င်းတို့ကိုယ်သူတို့ မပြသေးကြောင်းနှင့် ပိုမိုထူးခြားဆန်းပြားသော ချုံ့မှု algorithms များကို မစဉ်းစားခဲ့မိပါ)။

သိမ်းဆည်းခြင်း၏ ပြဿနာများကို ပြန်ကြည့်ရအောင်။

ဒုတိယ (သူတို့ပြောသလို အရေးမကြီးပါဘူး) ပြဿနာက အရင်အပိုင်းတွေကို အဆက်မပြတ် ကိုးကားထားတဲ့ Compressed data တစ်ခုတည်းက စီးကြောင်းတစ်ခုပါပဲ။ ထို့ကြောင့်၊ compressed data ၏ အပိုင်းအချို့ ပျက်စီးသွားပါက၊ ၎င်းနှင့် ဆက်စပ်နေသော ချုံ့မထားသော data block များသာမက နောက်ဆက်တွဲ အားလုံးကိုပါ ဆုံးရှုံးသွားပါမည်။

ဤပြဿနာကိုဖြေရှင်းရန်နည်းလမ်းများရှိသည်-

1. ပြဿနာမဖြစ်ပွားစေရန် တားဆီးပါ - အမှားများကို ရှာဖွေတွေ့ရှိပြီး ပြင်ပေးနိုင်ရန် ချုံ့ထားသောဒေတာတွင် ထပ်လောင်းထည့်ပါ။ ဒီအကြောင်းကို နောက်မှပြောမယ်။
2. ပြဿနာတစ်ခုဖြစ်ပေါ်လာပါက အကျိုးဆက်များကို လျှော့ချပါ။
   ဒေတာဘလောက်တစ်ခုစီကို အမှီအခိုကင်းစွာ ချုံ့နိုင်သည်ဟု ကျွန်ုပ်တို့ပြောထားပြီးသားဖြစ်ပြီး ပြဿနာက သူ့အလိုလို ပျောက်ကွယ်သွားလိမ့်မည် (ဘလောက်တစ်ခု၏ဒေတာပျက်စီးခြင်းသည် ဤဘလောက်တစ်ခုတည်းသာ ဒေတာဆုံးရှုံးသွားသည်)။ သို့သော်၊ ဤသည်မှာ လွန်ကဲသောကိစ္စဖြစ်ပြီး၊ ဒေတာချုံ့ခြင်းမှာ ထိရောက်မှုမရှိပါ။ ဆန့်ကျင်ဘက်လွန်ကဲ- ကျွန်ုပ်တို့၏ချစ်ပ်၏ 4 MB အားလုံးကို တစ်ခုတည်းသော မှတ်တမ်းအဖြစ် အသုံးပြုပါ၊ ၎င်းသည် ကျွန်ုပ်တို့အား အလွန်ကောင်းမွန်သော ဖိသိပ်မှုကို ပေးစွမ်းနိုင်သော်လည်း ဒေတာဖောက်ပြန်မှုတွင် ဆိုးရွားသောအကျိုးဆက်များဖြစ်သည်။
   ဟုတ်ကဲ့၊ ယုံကြည်စိတ်ချရမှုအရ အပေးအယူတစ်ခုလိုတယ်။ သို့သော် ကျွန်ုပ်တို့သည် အလွန်နိမ့်ကျသော BER နှင့် ဒေတာသိုလှောင်မှုသက်တမ်းကို အနှစ် 20 ဖြင့် မတည်ငြိမ်သောမှတ်ဉာဏ်အတွက် ဒေတာသိုလှောင်မှုပုံစံကို ဖော်ဆောင်နေကြောင်း သတိရရမည်ဖြစ်သည်။

စမ်းသပ်မှုများအတွင်း ချုံ့မှုအဆင့်တွင် သိသာထင်ရှားသောဆုံးရှုံးမှုများ 10 KB ထက်နည်းသော ချုံ့ထားသောဒေတာတုံးများဖြင့် စတင်သည်ကို ကျွန်ုပ်တွေ့ရှိခဲ့သည်။
အစောပိုင်းတွင် အသုံးပြုခဲ့သည့် မမ်မိုရီကို စာမျက်နှာတစ်ခုစီတွင် ဖော်ပြခဲ့ပြီး၊ သင် "စာမျက်နှာတစ်မျက်နှာ - ချုံ့ထားသောဒေတာတစ်တုံး" မြေပုံကို အသုံးမပြုသင့်သည့် အကြောင်းရင်းကို ကျွန်ုပ်မတွေ့ပါ။

ဆိုလိုသည်မှာ၊ အနည်းဆုံး ကျိုးကြောင်းဆီလျော်သော စာမျက်နှာအရွယ်အစားမှာ 16Kb (ဝန်ဆောင်မှုအချက်အလက်များအတွက် အရံတစ်ခုပါ) ဖြစ်သည်။ သို့သော်၊ ထိုကဲ့သို့သော သေးငယ်သော စာမျက်နှာအရွယ်အစားသည် အမြင့်ဆုံးစံချိန်အရွယ်အစားအပေါ် သိသာထင်ရှားသော ကန့်သတ်ချက်များ ချမှတ်ထားသည်။

compressed form မှာ ကီလိုဘိုက်အနည်းငယ်ထက် ပိုကြီးတဲ့ မှတ်တမ်းတွေရှိဖို့ မမျှော်လင့်ထားပေမယ့် 32K စာမျက်နှာတွေကို သုံးဖို့ ဆုံးဖြတ်လိုက်တယ် (တစ်ချပ်ကို 128 စာမျက်နှာ ပေးတယ်)။

အနှစ်ချုပ်:

• ကျွန်ုပ်တို့သည် zlib (deflate);
• ထည့်သွင်းမှုတစ်ခုစီအတွက် ကျွန်ုပ်တို့သည် Z_SYNC_FLUSH ကို သတ်မှတ်သည်။
• ချုံ့ထားသောမှတ်တမ်းတစ်ခုစီအတွက်၊ ကျွန်ုပ်တို့သည် နောက်လိုက်ဘိုက်များကို ချုံ့လိုက်ပါသည်။ (ဥပမာ 0x00၊ 0x00၊ 0xff၊ 0xff); ခေါင်းစီးတွင် ကျွန်ုပ်တို့ ဖြတ်တောက်ထားသော ဘိုက်မည်မျှရှိသည်ကို ဖော်ပြသည်။
• ဒေတာကို 32Kb စာမျက်နှာများတွင် သိမ်းဆည်းပါသည်။ စာမျက်နှာတစ်ခုစီတွင် ချုံ့ထားသောဒေတာစီးကြောင်းတစ်ခုစီပါရှိသည်။ စာမျက်နှာတစ်ခုစီတွင် ကျွန်ုပ်တို့သည် အသစ်တစ်ဖန် compression ကိုစတင်သည်။

compression ဖြင့်မပြီးမီ၊ မှတ်တမ်းတစ်ခုလျှင် compressed data များကို bytes အနည်းငယ်သာရနိုင်သည်ဟူသောအချက်ကို အာရုံစိုက်စေလိုသည်၊ ထို့ကြောင့် ဝန်ဆောင်မှုအချက်အလက်များကို တိုးမလာအောင်ပြုလုပ်ရန် အလွန်အရေးကြီးပါသည်၊ တစ်ဘိုက်တိုင်းသည် ဤနေရာတွင် ရေတွက်ပါသည်။

ဒေတာ ခေါင်းစီးများကို သိမ်းဆည်းခြင်း။

ကျွန်ုပ်တို့တွင် ပြောင်းလဲနိုင်သော အရှည်မှတ်တမ်းများ ရှိသောကြောင့်၊ မှတ်တမ်းများ၏ နေရာချထား/နယ်နိမိတ်များကို တစ်နည်းနည်းဖြင့် ဆုံးဖြတ်ရန် လိုအပ်ပါသည်။

ချဉ်းကပ်မှု သုံးခုကို ငါသိတယ်။

1. မှတ်တမ်းအားလုံးကို စဉ်ဆက်မပြတ်စီးကြောင်းတွင် သိမ်းဆည်းထားပြီး ပထမအလျားပါရှိသော မှတ်တမ်းခေါင်းစီး၊ ထို့နောက် မှတ်တမ်းကိုယ်တိုင် သိမ်းဆည်းထားသည်။
   ဤဗားရှင်းတွင်၊ ခေါင်းစီးနှင့် ဒေတာ နှစ်ခုစလုံးသည် ပြောင်းလဲနိုင်သော အရှည်ရှိသည်။
   အနှစ်သာရအားဖြင့်၊ ကျွန်ုပ်တို့သည် အချိန်တိုင်းအသုံးပြုနေသည့် တစ်ခုတည်းသော ချိတ်ဆက်ထားသောစာရင်းကို ရရှိပါသည်။
2. ခေါင်းစီးများနှင့် မှတ်တမ်းများကို ၎င်းတို့ကိုယ်တိုင် သီးခြားထုတ်လွှင့်မှုများတွင် သိမ်းဆည်းထားသည်။
   စဉ်ဆက်မပြတ် အရှည်ရှိသော ခေါင်းစီးများကို အသုံးပြုခြင်းဖြင့်၊ ခေါင်းစီးတစ်ခု၏ အကျင့်ပျက်ခြစားမှုသည် အခြားအရာများကို မထိခိုက်စေကြောင်း သေချာပါသည်။
   အလားတူနည်းလမ်းကို ဥပမာအားဖြင့် ဖိုင်စနစ်များစွာတွင် အသုံးပြုသည်။
3. မှတ်တမ်းများကို စဉ်ဆက်မပြတ်စီးကြောင်းတွင် သိမ်းဆည်းထားပြီး၊ မှတ်တမ်းနယ်နိမိတ်ကို အမှတ်အသားအချို့ (ဒေတာဘလောက်များတွင် တားမြစ်ထားသည့် သင်္ကေတ/အစီအစဥ်များ) မှ ဆုံးဖြတ်သည်။ မှတ်တမ်းတစ်ခုအတွင်း အမှတ်အသားတစ်ခုတွေ့ပါက၊ ၎င်းကို အစီအစဥ်အချို့ဖြင့် အစားထိုးသည် (ကျွန်ုပ်တို့သည် ၎င်းကို လွတ်ကင်းသည်)။
   အလားတူချဉ်းကပ်နည်းကို ဥပမာအားဖြင့် PPP ပရိုတိုကောတွင် အသုံးပြုသည်။

ဥပမာပေးပါရစေ။

Option ကို 1:

ဤတွင်အရာအားလုံးသည်အလွန်ရိုးရှင်းပါသည်- မှတ်တမ်း၏အရှည်ကိုသိခြင်းဖြင့်နောက်ခေါင်းစီး၏လိပ်စာကိုတွက်ချက်နိုင်သည်။ ထို့ကြောင့် ကျွန်ုပ်တို့သည် 0xff (အခမဲ့ ဧရိယာ) သို့မဟုတ် စာမျက်နှာ၏အဆုံးတွင် ပြည့်နေသည့် ဧရိယာကို မတွေ့မချင်း ခေါင်းစီးများမှတဆင့် ရွှေ့ပါ။

Option ကို 2:

မှတ်တမ်း၏ ပြောင်းလဲနိုင်သော အရှည်ကြောင့်၊ တစ်မျက်နှာလျှင် မည်မျှ မှတ်တမ်းများ (ထို့ကြောင့် ခေါင်းစီးများ) လိုအပ်မည်ကို ကျွန်ုပ်တို့ ကြိုတင် မပြောနိုင်ပါ။ ခေါင်းစီးများနှင့် ဒေတာများကို မတူညီသော စာမျက်နှာများတွင် ၎င်းတို့ကိုယ်တိုင် ဖြန့်ဝေနိုင်သော်လည်း အခြားနည်းလမ်းကို ကျွန်ုပ်ပိုနှစ်သက်သည်- ကျွန်ုပ်တို့သည် ခေါင်းစီးများနှင့် ဒေတာများကို စာမျက်နှာတစ်ခုတည်းတွင် ထားရှိသော်လည်း ခေါင်းစီးများ (ကိန်းသေအရွယ်အစား) သည် စာမျက်နှာ၏အစမှ စတင်ကာ ဒေတာ (ကွဲပြားနိုင်သော အရှည်) သည် အဆုံးမှ စတင်ပါသည်။ သူတို့ “တွေ့ဆုံ” သည်နှင့် တပြိုင်နက် (မှတ်တမ်းအသစ်အတွက် နေရာလွတ်အလုံအလောက်မရှိပါ)၊ ဤစာမျက်နှာကို ကျွန်ုပ်တို့ အပြည့်အဝစဉ်းစားပါသည်။

Option ကို 3:

ခေါင်းစီးရှိ ဒေတာတည်နေရာနှင့် ပတ်သက်သော အရှည် သို့မဟုတ် အခြားအချက်အလက်များကို သိမ်းဆည်းရန် မလိုအပ်ပါ၊ မှတ်တမ်းများ၏ နယ်နိမိတ်များကို ညွှန်ပြသည့် အမှတ်အသားများသည် လုံလောက်ပါသည်။ သို့သော် စာရေး/ဖတ်သည့်အခါ ဒေတာကို စီမံဆောင်ရွက်ရမည်။
အမှတ်အသားအဖြစ် 0xff (စာမျက်နှာကို ဖျက်ပြီးနောက် ဖြည့်ထားသည်)၊ ထို့ကြောင့် အခမဲ့ဧရိယာကို ဒေတာအဖြစ် မှတ်ယူမည်မဟုတ်ပါ။

နှိုင်းယှဉ်ဇယား-

option ကို 1
option ကို 2
option ကို 3

အမှားကို သည်းခံပါ။
-
+
+

သိပ်သည်းဆ
+
-
+

အကောင်အထည်ဖော်မှုရှုပ်ထွေး
*
**
**

ရွေးချယ်မှု 1 တွင် ဆိုးရွားသော ချို့ယွင်းချက်တစ်ခု ရှိသည်- ခေါင်းစီးတစ်ခု ပျက်စီးပါက နောက်ဆက်တွဲကွင်းဆက်တစ်ခုလုံး ပျက်စီးသွားမည်ဖြစ်သည်။ အခြားရွေးချယ်မှုများသည် သင့်အား ကြီးမားသောပျက်စီးဆုံးရှုံးမှုနှင့်ပင် ဒေတာ၏တစ်စိတ်တစ်ပိုင်းကို ပြန်လည်ရယူနိုင်သည်။
သို့သော် ဤနေရာတွင် ဒေတာကို ချုံ့ထားသောပုံစံဖြင့် သိမ်းဆည်းရန် ဆုံးဖြတ်ခဲ့သည်ကို မှတ်သားရန် သင့်လျော်ပြီး မည်သို့ပင်ဖြစ်စေ “ကျိုး” စံချိန်တင်ပြီးနောက် စာမျက်နှာပေါ်ရှိ ဒေတာအားလုံး ဆုံးရှုံးသွားသောကြောင့် ဇယားတွင် အနုတ်လက္ခဏာရှိသော်လည်း ၎င်းကို ထည့်သွင်းစဉ်းစားမည်မဟုတ်ပါ။

ကျစ်လစ်မှု-

• ပထမရွေးချယ်မှုတွင် ကျွန်ုပ်တို့သည် ခေါင်းစီးတွင် အလျားကို သိမ်းဆည်းရန်သာလိုသည်၊ အကယ်၍ ကျွန်ုပ်တို့သည် ပြောင်းလဲနိုင်သောအလျား-ကိန်းပြည့်များကို အသုံးပြုပါက၊ ကိစ္စအများစုတွင် ကျွန်ုပ်တို့သည် တစ်ဘိုက်ဖြင့် ရနိုင်သည်။
• ဒုတိယရွေးချယ်မှုတွင် ကျွန်ုပ်တို့သည် စတင်လိပ်စာနှင့် အရှည်ကို သိမ်းဆည်းရန် လိုအပ်သည်။ မှတ်တမ်းသည် ကိန်းသေအရွယ်အစားဖြစ်ရမည်၊ မှတ်တမ်းတစ်ခုလျှင် 4 bytes (အော့ဖ်ဆက်အတွက် နှစ်ဘိုက်၊ အရှည်အတွက် နှစ်ဘိုက်)
• တတိယရွေးချယ်မှုမှာ အသံသွင်းခြင်း၏အစကို ညွှန်ပြရန် ဇာတ်ကောင်တစ်ခုသာ လိုအပ်ပြီး စိစစ်ခြင်းကြောင့် အသံသွင်းခြင်းကိုယ်တိုင် 1-2% တိုးလာမည်ဖြစ်သည်။ ယေဘုယျအားဖြင့်၊ ၎င်းသည် ပထမရွေးချယ်မှုနှင့် တန်းတူဖြစ်သည်။

အစကတော့ ဒုတိယရွေးချယ်မှုကို ပင်မတစ်ခုအဖြစ် သတ်မှတ်ခဲ့တယ် (အကောင်အထည်ဖော်မှုတစ်ခုတောင် ရေးခဲ့တယ်)။ နောက်ဆုံးတော့ Compression ကိုသုံးဖို့ ဆုံးဖြတ်ပြီးမှသာ အဲဒါကို စွန့်လွှတ်ခဲ့တယ်။

တစ်နေ့ကျရင် ဒီလိုရွေးချယ်မှုမျိုးကို ကျွန်တော်သုံးနိုင်ပါလိမ့်မယ်။ ဥပမာအားဖြင့်၊ အကယ်၍ ကျွန်ုပ်သည် ကမ္ဘာနှင့် အင်္ဂါဂြိုလ်ကြား သွားလာနေသော သင်္ဘောအတွက် ဒေတာသိုလှောင်မှုနှင့် ပတ်သက်ရလျှင် - ယုံကြည်စိတ်ချရမှု၊ စကြာဝဠာရောင်ခြည်အတွက် လိုအပ်ချက်များ၊ ...

တတိယရွေးချယ်ခွင့်အတွက်၊ အကောင်အထည်ဖော်မှု၏ ရှုပ်ထွေးမှုအတွက် ကြယ်နှစ်ပွင့်ကို ကျွန်ုပ်သည် ပြေးလွှားခြင်း၊ လုပ်ငန်းစဉ်တွင် အရှည်ပြောင်းခြင်းစသည်တို့ကို မကြိုက်သောကြောင့် ကြယ်နှစ်ပွင့်ကို ပေးခဲ့ပါသည်။ ဟုတ်တယ်၊ ဘက်လိုက်မှုဖြစ်နိုင်ပေမယ့် ကုဒ်ကိုရေးရပါလိမ့်မယ် - ကိုယ်မကြိုက်တဲ့အရာကို ဘာကြောင့် အတင်းလုပ်ခိုင်းတာလဲ။

အနှစ်ချုပ်: ၎င်း၏ထိရောက်မှုနှင့် အကောင်အထည်ဖော်ရလွယ်ကူမှုကြောင့် ကျွန်ုပ်တို့သည် “အလျားနှင့် ခေါင်းစီး-ပြောင်းလဲနိုင်သော အရှည်ဒေတာ” ကွင်းဆက်များပုံစံ သိုလှောင်မှုရွေးချယ်မှုကို ရွေးချယ်ပါသည်။

စာရေးခြင်းလုပ်ငန်းအောင်မြင်မှုကို စောင့်ကြည့်ရန် ဘစ်အကွက်များကို အသုံးပြုခြင်း။

အကြံအစည်ကို ဘယ်ကရခဲ့တာလဲဆိုတာ အခုမှ မမှတ်မိတော့ပေမယ့် ဒါက ဒီလိုမျိုး တွေ့ရတယ်။
ထည့်သွင်းမှုတစ်ခုစီအတွက်၊ ကျွန်ုပ်တို့သည် အလံများကိုသိမ်းဆည်းရန် ဘစ်များစွာကို ခွဲဝေပေးပါသည်။
အစောပိုင်းတွင် ကျွန်ုပ်တို့ပြောခဲ့သည့်အတိုင်း၊ ဖျက်ပြီးနောက် bits အားလုံးကို 1 နှင့်ဖြည့်ပြီး 1 မှ 0 သို့ပြောင်းနိုင်သော်လည်း အပြန်အလှန်မပြောင်းပါ။ ဒါကြောင့် "flag not set" အတွက် 1၊ "flag set" - 0 ကို သုံးပါတယ်။

ဤအရာသည် ပြောင်းလဲနိုင်သော အရှည်မှတ်တမ်းကို flash တွင် ထည့်သွင်းခြင်းကဲ့သို့ ဖြစ်နိုင်ပါသည်။

1. "အရှည်မှတ်တမ်းတင်ခြင်းစတင်သည်" အလံကိုသတ်မှတ်ပါ။
2. အရှည်ကို ချရေးပါ။
3. “ဒေတာမှတ်တမ်းတင်ခြင်း စတင်ပြီ” အလံကို သတ်မှတ်ပါ။
4. ငါတို့သည်ဒေတာကိုရေး;
5. ကျွန်ုပ်တို့သည် "မှတ်တမ်းတင်ခြင်းပြီးဆုံးသည်" ဟုအလံသတ်မှတ်ထားသည်။

ထို့အပြင်၊ စုစုပေါင်းဘစ်အလံ 4 ခုအတွက် "အမှားတစ်ခုဖြစ်ပွားခဲ့သည်" အလံတစ်ခုရှိသည်။

ဤအခြေအနေတွင် ကျွန်ုပ်တို့တွင် “1111” တည်ငြိမ်သောပြည်နယ်နှစ်ခုရှိသည် – အသံသွင်းခြင်းမစတင်သေးဘဲ “1000” – မှတ်တမ်းတင်ခြင်းအောင်မြင်ပါသည်။ မှတ်တမ်းတင်ခြင်းလုပ်ငန်းစဉ်၏ မမျှော်လင့်ဘဲ ပြတ်တောက်သွားသောအခါတွင် ကျွန်ုပ်တို့သည် အလယ်အလတ်ပြည်နယ်များကို ရှာဖွေတွေ့ရှိနိုင်ပြီး နောက်ပိုင်းတွင် လုပ်ဆောင်နိုင်မည်ဖြစ်သည်။

ချဉ်းကပ်မှုသည် စိတ်ဝင်စားစရာကောင်းသည်၊ သို့သော် ၎င်းသည် ရုတ်တရက် ဓာတ်အားပြတ်တောက်မှုနှင့် အလားတူကျရှုံးမှုများကိုသာ ကာကွယ်ပေးသည်၊ ၎င်းသည် အရေးကြီးသည်၊ သို့သော် ယင်းသည် ဖြစ်နိုင်ချေရှိသော ဆုံးရှုံးမှုများအတွက် တစ်ခုတည်းသော (အဓိကအကြောင်းရင်းမဟုတ်) နှင့် ဝေးပါသည်။

အနှစ်ချုပ်: အဖြေကောင်းကို ရှာကြည့်ရအောင်။

ငွေစာရင်းများ

Checksums သည် ကျွန်ုပ်တို့ ရေးထားသည်ကို အတိအကျဖတ်နေသည် (ကျိုးကြောင်းဆီလျော် ဖြစ်နိုင်ခြေရှိသော) ကို အတည်ပြုရန် နည်းလမ်းကိုလည်း ပေးပါသည်။ အထက်တွင် ဆွေးနွေးထားသော နယ်ပယ်များနှင့် မတူဘဲ၊ ၎င်းတို့သည် အမြဲတမ်း အလုပ်လုပ်ပါသည်။

အထက်တွင် ဆွေးနွေးခဲ့သည့် ပြဿနာများ၏ ဖြစ်နိုင်ခြေအရင်းအမြစ်များစာရင်းကို သုံးသပ်ပါက၊ checksum သည် ၎င်း၏ဇာစ်မြစ်ကို မခွဲခြားဘဲ အမှားတစ်ခုကို အသိအမှတ်ပြုနိုင်သည်။ (ဖြစ်ကောင်းဖြစ်နိုင်၊ မကောင်းသောဂြိုလ်သားများမှလွဲ၍ - သူတို့သည် checksum ကိုလည်းအတုယူနိုင်သည်).

ထို့ကြောင့် ကျွန်ုပ်တို့၏ရည်မှန်းချက်သည် ဒေတာနဂိုအတိုင်းဖြစ်ကြောင်း စစ်ဆေးရန်ဖြစ်ပါက၊ checksums သည် ကောင်းမွန်သောအကြံဥာဏ်တစ်ခုဖြစ်သည်။

checksum တွက်ချက်ခြင်းအတွက် algorithm ၏ရွေးချယ်မှုသည် မည်သည့်မေးခွန်းမှ မပေါ်ပေါက်ခဲ့ပါ - CRC။ တစ်ဖက်တွင်၊ သင်္ချာဂုဏ်သတ္တိများသည် အချို့သောအမျိုးအစားများ၏ အမှားများကို 100% ဖမ်းယူနိုင်စေသည်၊ အခြားတစ်ဖက်တွင် - ကျပန်းဒေတာတွင် ဤ algorithm သည် များသောအားဖြင့် သီအိုရီကန့်သတ်ချက်ထက် များစွာမမြင့်မားဘဲ တိုက်မိမှုဖြစ်နိုင်ခြေကို ပြသည် . ၎င်းသည် အလျင်မြန်ဆုံး အယ်လဂိုရီသမ်မဟုတ်ပါ၊ ၎င်းသည် အမြဲတမ်း တိုက်မိမှု အနည်းဆုံးဖြစ်နိုင်သော်လည်း ၎င်းတွင် အလွန်အရေးကြီးသော အရည်အသွေးတစ်ခု ရှိသည်- ကျွန်ုပ်ကြုံတွေ့ခဲ့ရသော စမ်းသပ်မှုများတွင် ပြတ်ပြတ်သားသား ကျရှုံးမည့်ပုံစံများ မရှိခဲ့ပါ။ ဤကိစ္စတွင် တည်ငြိမ်မှုသည် အဓိက အရည်အသွေးဖြစ်သည်။

volumetric လေ့လာမှု၏ ဥပမာ- အပိုင်း 1, အပိုင်း 2 (narod.ru သို့လင့်ခ်များ၊ တောင်းပန်ပါတယ်).

သို့သော်၊ checksum ကိုရွေးချယ်ခြင်း၏တာဝန်သည်မပြီးသေးပါ၊ CRC သည် checksums မိသားစုတစ်ခုဖြစ်သည်။ အရှည်ကို ဆုံးဖြတ်ပြီး ကိန်းဂဏန်းတစ်ခုကို ရွေးချယ်ပါ။

checksum အရှည်ကိုရွေးချယ်ခြင်းသည် ပထမတစ်ချက်တွင် ထင်ရသကဲ့သို့ ရိုးရှင်းသောမေးခွန်းမဟုတ်ပါ။

ဥပမာပေးပါရစေ။
byte တစ်ခုစီတွင် error ဖြစ်နိုင်ခြေရှိကြပါစို့ နှင့် စံပြ checksum သည် မှတ်တမ်းပေါင်း သန်းတစ်ထောင်လျှင် ပျမ်းမျှအမှားအယွင်း အရေအတွက်ကို တွက်ချက်သည်-

ဒေတာ၊ ဘိုက်
Checksum၊ byte
မသိနိုင်သော အမှားများ
မှားယွင်းသော အပြုသဘောဆောင်သော အမှားရှာဖွေမှုများ
မှားယွင်းသော တုံ့ပြန်မှု စုစုပေါင်း အရေအတွက်

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

အရာအားလုံးရိုးရှင်းပုံရသည် - ကာကွယ်ထားသောဒေတာ၏ကြာချိန်ပေါ်မူတည်၍ မှားယွင်းသောအချက်များအနည်းဆုံးဖြင့် checksum ၏အရှည်ကိုရွေးချယ်ပါ - ပြီးပါပြီ။

သို့သော်၊ တိုတောင်းသော checksums များတွင် ပြဿနာတစ်ခုရှိသည်- ၎င်းတို့သည် တစ်ခုတည်းသော bit error များကိုရှာဖွေရာတွင် ကောင်းမွန်သော်လည်း၊ ၎င်းတို့သည် အလွန်မြင့်မားသောဖြစ်နိုင်ခြေဖြင့် လုံးလုံးကျပန်းဒေတာကို အမှန်အတိုင်းလက်ခံနိုင်သည်။ Habr တွင် ဖော်ပြသည့် ဆောင်းပါးတစ်ပုဒ် ရှိနှင့်ပြီးဖြစ်သည်။ လက်တွေ့ဘဝတွင် ပြဿနာ.

ထို့ကြောင့်၊ ကျပန်း checksum သည် မဖြစ်နိုင်သလောက် ကိုက်ညီစေရန်၊ 32 bits သို့မဟုတ် ထိုထက်ပိုသော checksums ကို အသုံးပြုသင့်သည်။ (64 bits ထက်ကြီးသော အရှည်အတွက်၊ cryptographic hash လုပ်ဆောင်ချက်များကို အများအားဖြင့် အသုံးပြုသည်).

ကုန်ကျစရိတ်အားလုံးအတွက် နေရာချွေတာဖို့လိုတယ်လို့ စောစောကရေးခဲ့ပေမဲ့၊ 32-bit checksum (16 bits က မလုံလောက်ဘူး၊ တိုက်မိမှုဖြစ်နိုင်ခြေက 0.01% ထက် ပိုများတယ်၊ သူတို့ပြောသလို 24 bits က ဒီမှာရော ဟိုမှာရော မရှိဘူး)။

ဤနေရာတွင် ကန့်ကွက်မှုတစ်ခု ဖြစ်ပေါ်လာနိုင်သည်- ယခု 4 bytes ကို တစ်ပြိုင်နက် ပေးနိုင်ရန် compression ကို ရွေးချယ်ရာတွင် ဘိုက်တိုင်းကို သိမ်းဆည်းထားပါသလား။ ချုံ့ပြီး ချက်ဆမ်မထည့်တာ ပိုကောင်းမှာ မဟုတ်ဘူးလား။ နှိမ်မှုမရှိတာတော့ မဟုတ်ပါဘူး။ မဆိုလိုပါ။သမာဓိစစ်ဆေးရန် မလိုအပ်ပါ။

polynomial တစ်ခုကို ရွေးချယ်သည့်အခါ ဘီးကို ပြန်လည်မွမ်းမံမည်မဟုတ်သော်လည်း ယခုလူကြိုက်များသော CRC-32C ကို ယူပါမည်။
ဤကုဒ်သည် 6 bytes အထိ packet များတွင် 22 bit အမှားအယွင်းများ (ကျွန်ုပ်တို့အတွက် အဖြစ်များဆုံး ဖြစ်ကောင်းဖြစ်နိုင်သည်)၊ 4 bytes အထိ packet များတွင် 655 bit အမှားအယွင်းများ (ကျွန်ုပ်တို့အတွက်လည်း ဖြစ်ရိုးဖြစ်စဉ်တစ်ခု)၊ ကျိုးကြောင်းဆီလျော်သော အရှည်ရှိ packets များတွင် odd number of bit အမှားအယွင်း 2 ခု သို့မဟုတ် odd number of bit error တစ်ခုခုကို ဤကုဒ်က တွေ့ရှိပါသည်။

အသေးစိတ်ကို စိတ်ဝင်စားသူရှိရင်

ဝီကီပီးဒီးယား ဆောင်းပါး CRC အကြောင်း။

ကုဒ် ကန့်သတ်ချက်များ crc-32c အပေါ် Kupman ၏ website တွင် - ကမ္ဘာပေါ်ရှိ ထိပ်တန်း CRC ကျွမ်းကျင်သူဖြစ်နိုင်သည်။

В သူ့ဆောင်းပါး ဖြစ် နောက်ထပ်စိတ်ဝင်စားဖို့ကောင်းတဲ့ကုဒ်ကျွန်ုပ်တို့နှင့်သက်ဆိုင်သည့် ပက်ကက်အရှည်များအတွက် အနည်းငယ်ပိုကောင်းသော ဘောင်များကို ပံ့ပိုးပေးသော၊ သို့သော် ခြားနားချက်ကို သိသာထင်ရှားစွာ မစဉ်းစားခဲ့ဘဲ၊ စံနှုန်းနှင့် ကောင်းမွန်စွာ သုတေသနပြုထားသည့် စံနှုန်းအစား စိတ်ကြိုက်ကုဒ်ကို ရွေးချယ်ရန် လုံလောက်သော အရည်အချင်းမရှိဟု ကျွန်တော် မယူဆခဲ့ပါ။

ကျွန်ုပ်တို့၏ဒေတာကို ချုံ့ထားသောကြောင့် မေးခွန်းပေါ်လာသည်- ကျွန်ုပ်တို့သည် ချုံ့ထားသော သို့မဟုတ် ချုံ့မထားသောဒေတာ၏ checksum ကို တွက်ချက်သင့်ပါသလား။

ချုံ့မထားသောဒေတာ၏ checksum ကို တွက်ချက်ရန် အကြောင်းပြချက်များ-

• ကျွန်ုပ်တို့သည် နောက်ဆုံးတွင် ဒေတာသိမ်းဆည်းခြင်း၏ ဘေးကင်းမှုကို စစ်ဆေးရန် လိုအပ်သည် - ထို့ကြောင့် ကျွန်ုပ်တို့သည် ၎င်းကို တိုက်ရိုက်စစ်ဆေးခြင်း (တစ်ချိန်တည်းတွင်၊ ဖိသိပ်မှု/ချုံ့ချဲ့ခြင်း၏ အကောင်အထည်ဖော်မှုတွင် ဖြစ်နိုင်သော အမှားအယွင်းများ၊ မကောင်းတဲ့ မှတ်ဉာဏ်ကြောင့် ပျက်စီးခြင်း စသည်ဖြင့် စစ်ဆေးသွားပါမည်)။
• zlib ရှိ deflate algorithm သည် အတော်အတန် ရင့်ကျက်သော အကောင်အထည်ဖော်မှုနှင့် ရှိပါသည်။ မပေးသင့်ပါတယ် "ကောက်ကွေးသော" ထည့်သွင်းမှုဒေတာနှင့်အတူ ကျဆင်းသွားသည်၊ ထို့အပြင်၊ ၎င်းသည် မကြာခဏဆိုသလို input stream တွင် အမှားအယွင်းများကို သီးခြားရှာဖွေတွေ့ရှိနိုင်ပြီး အမှားတစ်ခုအား ဖော်ထုတ်ခြင်း၏ အလုံးစုံဖြစ်နိုင်ခြေကို လျှော့ချနိုင်သည် (ကျွန်တော်သည် မှတ်တမ်းတိုတစ်ခုအတွင်း ဘစ်တစ်ခု၏ ပြောင်းပြန်လှန်မှုဖြင့် စမ်းသပ်မှုတစ်ခုကို ပြုလုပ်ခဲ့ပြီး၊ zlib သည် ဖြစ်ရပ်များ၏ သုံးပုံတစ်ပုံခန့်တွင် အမှားတစ်ခုတွေ့ရှိခဲ့သည်)။

ချုံ့မထားသော ဒေတာများ၏ checksum ကို တွက်ချက်ခြင်းအပေါ် ငြင်းခုံချက်များ-

• CRC သည် flash memory အတွက် ပုံမှန်ဖြစ်သော bit error အနည်းငယ်အတွက် သီးသန့်ဖြစ်သည် ( compressed stream တွင် bit error သည် output stream တွင် ကြီးမားသောပြောင်းလဲမှုဖြစ်စေနိုင်ပြီး၊ သီအိုရီသက်သက်ဖြင့်၊ ကျွန်ုပ်တို့သည် collision ကိုဖမ်းနိုင်သည်)
• ပျက်သွားနိုင်တဲ့ data တွေကို decompressor မှာ ကျွေးတာ မကြိုက်ဘူး၊ ဘယ်သူသိနိုင်မလဲသူဘယ်လိုတုံ့ပြန်မလဲ။

ဤပရောဂျက်တွင် ကျွန်ုပ်သည် ချုံ့မထားသော ဒေတာ ချက်လက်မှတ်ကို သိမ်းဆည်းခြင်း၏ ဘုံအလေ့အထမှ ဖယ်ခွာရန် ဆုံးဖြတ်ခဲ့သည်။

အနှစ်ချုပ်: ကျွန်ုပ်တို့သည် CRC-32C ကိုအသုံးပြုသည်၊ ၎င်းတို့ကို flash သို့ရေးသားထားသောပုံစံ (ချုံ့ပြီးနောက်) ဒေတာမှ checksum ကိုတွက်ချက်သည်။

ပိုများခြင်း။

မလိုအပ်သော coding ကိုအသုံးပြုခြင်းသည် ဒေတာဆုံးရှုံးမှုကို ဖယ်ရှားပေးမည်မဟုတ်ပေ။ သို့သော်လည်း၊ ၎င်းသည် ပြန်လည်ပြုပြင်၍မရသော ဒေတာဆုံးရှုံးမှု ဖြစ်နိုင်ခြေကို (မကြာခဏ ပြင်းအားများစွာဖြင့်) သိသိသာသာ လျှော့ချနိုင်သည်။

အမှားများကိုပြင်ရန် ကွဲပြားသော ထပ်နေသောအမျိုးအစားများကို အသုံးပြုနိုင်သည်။
Hamming ကုဒ်များသည် တစ်ခုတည်းသော အမှားများကို ပြင်ပေးနိုင်သည်၊ Reed-Solomon ကုဒ်များသည် သင်္ကေတများ၊ checksums များနှင့်အတူ ဒေတာမိတ္တူများစွာ၊ သို့မဟုတ် RAID-6 ကဲ့သို့ ကုဒ်နံပါတ်များသည် ကြီးမားသော အကျင့်ပျက်ခြစားမှုဖြစ်ပွားသည့်တိုင် ဒေတာပြန်လည်ရယူရန် ကူညီပေးနိုင်ပါသည်။
အစပိုင်းမှာတော့ error-correcting coding ကို တွင်တွင်ကျယ်ကျယ် အသုံးပြုနေခဲ့တယ်၊ ဒါပေမယ့် အမှားအယွင်းတွေကို ကာကွယ်လိုတဲ့ အကြံဥာဏ်တစ်ခုရှိဖို့ လိုအပ်ပြီး coding ကို ရွေးချယ်ဖို့ လိုအပ်တယ်ဆိုတာကို အစကတော့ နားလည်ခဲ့ပါတယ်။

အမှားအယွင်းများကို တတ်နိုင်သမျှ အမြန်ဖော်ထုတ်ရန် လိုအပ်ကြောင်း အစောပိုင်းတွင် ပြောကြားခဲ့ပါသည်။ ဘယ်အချက်တွေမှာ အမှားအယွင်းတွေ ကြုံရနိုင်မလဲ။

1. မပြီးဆုံးသေးသော အသံသွင်းခြင်း (အကြောင်းတစ်ခုခုကြောင့်၊ ရိုက်ကူးနေစဉ် ပါဝါပြတ်သွားသည်၊ Raspberry အေးခဲသွားသည်၊ ...)
   ကံမကောင်းစွာပဲ၊ ထိုကဲ့သို့သော အမှားအယွင်းတစ်ခုအတွက်၊ တစ်ခုတည်းသောရွေးချယ်မှုသည် မမှန်ကန်သောမှတ်တမ်းများကို လျစ်လျူရှုပြီး ပျောက်ဆုံးသွားသောဒေတာကို ထည့်သွင်းစဉ်းစားရန်ဖြစ်သည်။
2. အမှားများ ရေးပါ (အကြောင်းတစ်ခုခုကြောင့်၊ ရေးထားသည့်အရာမှလွဲ၍ အခြားတစ်ခုခုကို flash memory သို့ ရေးထားသည်)
   မှတ်တမ်းတင်ပြီးပြီးချင်း ထိန်းချုပ်ဖတ်ရှုခြင်းကို လုပ်ဆောင်ပါက ထိုကဲ့သို့သော အမှားအယွင်းများကို ချက်ချင်းသိရှိနိုင်မည်ဖြစ်သည်။
3. သိမ်းဆည်းစဉ်အတွင်း မှတ်ဉာဏ်ထဲတွင် ဒေတာပျက်စီးခြင်း၊
4. စာဖတ်ခြင်းအမှားများ
   အမှားကိုပြင်ရန်၊ checksum နှင့်မကိုက်ညီပါက၊ အကြိမ်များစွာပြန်ဖတ်ရန်လုံလောက်သည်။

ဆိုလိုသည်မှာ၊ တတိယအမျိုးအစား၏ အမှားများ (သိုလှောင်မှုအတွင်း ဒေတာများ အလိုအလျောက် ဖောက်ပြန်ခြင်း) သည် error-correct coding မပါဘဲ ပြုပြင်၍မရပါ။ ထိုသို့သော အမှားများသည် အလွန်ဖြစ်နိုင်ချေရှိသည်ဟု ထင်မြင်ပါသည်။

အနှစ်ချုပ်: မလိုအပ်သော coding ကို စွန့်လွှတ်ရန် ဆုံးဖြတ်ခဲ့သည်၊ သို့သော် လုပ်ဆောင်ချက်သည် ဤဆုံးဖြတ်ချက်၏ မှားယွင်းမှုကို ပြသပါက ပြဿနာကို သုံးသပ်ခြင်းသို့ ပြန်သွားရန် (အကောင်းဆုံးသော coding အမျိုးအစားကို ရွေးချယ်ခွင့်ပြုမည့် ပျက်ကွက်မှုများဆိုင်ရာ ကိန်းဂဏန်းများ စုစည်းထားပြီးဖြစ်သည်)။

Прочее

ဟုတ်ပါတယ်၊ ဆောင်းပါး၏ဖော်မတ်သည် ဖော်မတ်ရှိ bit တိုင်းကို တရားမျှတစေရန် ခွင့်မပြုပါ။ (ငါ ခွန်အားတွေ ကုန်နေပြီ)ဒါကြောင့် စောစောက မထိမိတဲ့ အချက်တချို့ကို အကျဉ်းချုံးပြီး ပြောပြပါမယ်။

• စာမျက်နှာအားလုံးကို "တန်းတူ" လုပ်ရန် ဆုံးဖြတ်ခဲ့သည်၊
  ဆိုလိုသည်မှာ၊ မက်တာဒေတာ၊ သီးခြားစီးကြောင်းများ စသည်တို့ပါသည့် အထူးစာမျက်နှာများ ရှိမည်မဟုတ်ပါ၊ ၎င်းအစား စာမျက်နှာအားလုံးကို အလှည့်ကျ ပြန်ရေးသည့် stream တစ်ခုတည်းရှိပါမည်။
  ၎င်းသည် စာမျက်နှာများ ဝတ်ဆင်ခြင်းကိုပင် သေချာစေသည်၊ ရှုံးနိမ့်မှု၏ တစ်ခုတည်းသောအချက်မရှိ၊
• ဖော်မတ်၏ မူကွဲအတွက် ပံ့ပိုးပေးရန် အရေးကြီးသည်။
  ခေါင်းစီးရှိ ဗားရှင်းနံပါတ်မပါသော ဖော်မတ်သည် မကောင်းပါ။
  အသုံးပြုထားသော ဖော်မတ်ဗားရှင်းကို ညွှန်ပြမည့် စာမျက်နှာ ခေါင်းစီးတွင် အချို့သော Magic Number (လက်မှတ်) ပါသော အကွက်တစ်ခုကို ထည့်ရန် လုံလောက်ပါသည်။ (လက်တွေ့မှာ တစ်ဒါဇင်လောက်တောင် ရှိမယ်မထင်ဘူး);
• မှတ်တမ်းများအတွက် ပြောင်းလဲနိုင်သော အရှည်ခေါင်းစီးကို အသုံးပြုပါ (အများအပြားရှိသည့်အနက်)၊ ကိစ္စအများစုတွင် ၎င်းကို 1 byte ရှည်စေရန် ကြိုးစားပါ။
• ခေါင်းစီးအရှည်နှင့် ချုံ့ထားသော မှတ်တမ်း၏ ဖြတ်တောက်ထားသော အပိုင်း၏ အရှည်ကို ကုဒ်လုပ်ရန်၊ ပြောင်းလဲနိုင်သော အလျား-အလျား ဒွိကုဒ်များကို အသုံးပြုပါ။

အလွန်အထောက်အကူဖြစ်ခဲ့သည်။ အွန်လိုင်းမီးစက် Huffman ကုဒ်များ မိနစ်အနည်းငယ်အတွင်း လိုအပ်သော ပြောင်းလဲနိုင်သော-အရှည်ကုဒ်များကို ရွေးချယ်နိုင်ခဲ့သည်။

ဒေတာသိုလှောင်မှုပုံစံ၏ ရှင်းလင်းချက်

ဘိုက်အော်

တစ်ဘိုက်ထက် ပိုကြီးသော အကွက်များကို big-endian ဖော်မတ် (ကွန်ရက် ဘိုက်အမှာစာ) ဖြင့် သိမ်းထားသည်၊ ဆိုလိုသည်မှာ 0x1234 ကို 0x12, 0x34 အဖြစ် ရေးထားသည်။

စာမျက်နှာများခွဲပါ။

flash memory အားလုံးကို အရွယ်အစားတူ စာမျက်နှာများအဖြစ် ပိုင်းခြားထားသည်။

မူရင်းစာမျက်နှာအရွယ်အစားမှာ 32Kb ဖြစ်သော်လည်း မန်မိုရီချစ်ပ်၏ စုစုပေါင်းအရွယ်အစား၏ 1/4 ထက် မပိုပါ (4MB ချစ်ပ်အတွက်၊ ၎င်းမှာ 128 စာမျက်နှာဖြစ်သည်)။

စာမျက်နှာတစ်ခုစီသည် အခြားစာမျက်နှာတစ်ခုမှ အချက်အလက်များကို အခြားစာမျက်နှာတစ်ခုမှ ဒေတာကို ရည်ညွှန်းခြင်းမရှိပါ)။

စာမျက်နှာအားလုံးကို သဘာဝအစဉ်လိုက် (လိပ်စာများ၏ ငယ်စဉ်အလိုက်) နံပါတ် 0 ဖြင့် စတင်သည် (သုညစာမျက်နှာသည် လိပ်စာ 0 နှင့် စတင်သည်၊ ပထမ- 32Kb နှင့် ဒုတိယ- 64Kb စသည်ဖြင့်)

မန်မိုရီချစ်ပ်ကို ring buffer အဖြစ်အသုံးပြုသည်၊ ဆိုလိုသည်မှာ၊ ပထမဦးစွာမှတ်တမ်းတင်ခြင်းသည် စာမျက်နှာနံပါတ် 0 သို့သွားသည်၊ ထို့နောက် စာမျက်နှာနံပါတ် 1၊ ...၊ နောက်ဆုံးစာမျက်နှာကိုဖြည့်သောအခါ၊ စက်ဝိုင်းအသစ်တစ်ခုစတင်ပြီး စာမျက်နှာသုညမှ ဆက်လက်မှတ်တမ်းတင်သည်။

စာမျက်နှာအတွင်းပိုင်း

စာမျက်နှာ၏အစတွင် 4-byte စာမျက်နှာခေါင်းစီးကို သိမ်းဆည်းထားပြီး၊ ထို့နောက် ခေါင်းစီးစစ်ဆေးမှုတစ်ခု (CRC-32C)၊ ထို့နောက် မှတ်တမ်းများကို "header၊ data၊ checksum" ပုံစံဖြင့် သိမ်းဆည်းထားသည်။

စာမျက်နှာ ခေါင်းစီး (ပုံကြမ်းတွင် စိမ်းစိုညစ်ပတ်) ပါဝင်သည်-

• two-byte Magic Number အကွက် (ဖော်မတ်ဗားရှင်း ညွှန်ပြချက်ဟုလည်း ခေါ်သည်)
  လက်ရှိဗားရှင်းအတွက် ၎င်းကို ဖော်မတ်အဖြစ် သတ်မှတ်သည်။ 0xed00 ⊕ номер страницы;
• two-byte counter "Page Version" (memory rewrite cycle number)။

စာမျက်နှာပေါ်ရှိ မှတ်တမ်းများကို ချုံ့ထားသောပုံစံ ( deflate algorithm ကို အသုံးပြု၍ ) သိမ်းဆည်းထားသည်။ စာမျက်နှာတစ်ခုပေါ်ရှိ မှတ်တမ်းအားလုံးကို ထုတ်လွှင့်မှုတစ်ခုတွင် (ဘုံအဘိဓာန်တစ်ခုအသုံးပြု၍) ချုံ့ထားပြီး စာမျက်နှာအသစ်တစ်ခုစီတွင် ဖိသိပ်မှုအသစ်စတင်သည်။ ဆိုလိုသည်မှာ၊ မည်သည့်မှတ်တမ်းကိုမဆို ချုံ့ရန်၊ ဤစာမျက်နှာမှ ယခင်မှတ်တမ်းများအားလုံးကို (ဤစာမျက်နှာမှသာလျှင်) လိုအပ်ပါသည်။

မှတ်တမ်းတစ်ခုစီကို Z_SYNC_FLUSH အလံဖြင့် ချုံ့ထားပြီး၊ ရလဒ်အနေဖြင့် 4 bytes 0x00, 0x00, 0xff, 0xff, XNUMX bytes XNUMXxXNUMX, XNUMXxXNUMX, XNUMXxff, XNUMXxff, တစ်ခု သို့မဟုတ် နှစ်ခုထက်ပို၍ သုညဘိုက်များရှေ့တွင် ဖြစ်နိုင်ပါသည်။
flash memory သို့ စာရေးသည့်အခါ ဤ sequence (4၊ 5 သို့မဟုတ် 6 bytes ရှည်) ကို စွန့်ပစ်ပါ။

မှတ်တမ်းခေါင်းစီးသည် 1၊ 2 သို့မဟုတ် 3 bytes ဖြစ်ပြီး၊ သိမ်းဆည်းသည်-

• မှတ်တမ်းအမျိုးအစားကို ညွှန်ပြသော တစ်ဘစ် (T) - 0 - ဆက်စပ်ပစ္စည်း၊ 1 - မှတ်တမ်း;
• ပြောင်းလဲနိုင်သော အရှည်အကွက် (S) သည် 1 မှ 7 ဘစ်အထိ၊ ထုပ်ပိုးခြင်းအတွက် မှတ်တမ်းတွင် ထည့်ရမည့် ခေါင်းစီး၏အရှည်နှင့် "အမြီး" ကို သတ်မှတ်ခြင်း၊
• မှတ်တမ်းအရှည် (L)။

S တန်ဖိုးများ ဇယား-

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 (ချုံ့ထားသောဒေတာ၏ ဘိုက်အလျား)ကို ညွှန်ပြသည်၊၊ အပြာရောင်သည် ချုံ့ထားသောဒေတာကို ညွှန်ပြသည်၊ အနီရောင်သည် flash memory သို့မရေးထားသော compressed data ၏ နောက်ဆုံး bytes ကို ညွှန်ပြသည်။

ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် တစ်ဘိုက်တွင် အသုံးအများဆုံး အရှည် (63+5 bytes အထိ) မှတ်တမ်းများ၏ ခေါင်းစီးများကို ရေးနိုင်သည်။

ရေးပြီးတိုင်း၊ ယခင် checksum ၏ ပြောင်းပြန်တန်ဖိုးကို ကနဦးတန်ဖိုး (init) အဖြစ် အသုံးပြုသည့် CRC-32C checksum ကို သိမ်းဆည်းထားသည်။

CRC တွင် "ကြာချိန်" ၏ပိုင်ဆိုင်မှုတွင် အောက်ပါဖော်မြူလာ အလုပ်လုပ်သည် (လုပ်ငန်းစဉ်တွင် အပေါင်း သို့မဟုတ် အနုတ်ဘစ်ပြောင်းပြန်လှန်ခြင်း)။ .
ဆိုလိုသည်မှာ၊ ဤစာမျက်နှာရှိ ယခင် header bytes နှင့် data အားလုံး၏ CRC ကို အမှန်တကယ် တွက်ချက်ပါသည်။

checksum ပြီးနောက်ချက်ချင်းနောက်မှတ်တမ်း၏ခေါင်းစီးဖြစ်သည်။

ခေါင်းစီးသည် ၎င်း၏ပထမဘိုက်အား 0x00 နှင့် 0xff တို့နှင့် အမြဲကွာခြားနေစေရန် ဒီဇိုင်းထုတ်ထားပါသည်။ (ကျွန်ုပ်တို့သည် ခေါင်းစီး၏ပထမဘိုက်အစား 0xff နှင့် ကြုံတွေ့ရပါက ၎င်းမှာ အသုံးမပြုသောဧရိယာဖြစ်သည်၊ 0x00 သည် အမှားအယွင်းတစ်ခုဖြစ်ကြောင်း အချက်ပြသည်)။

နမူနာ algorithms

flash memory မှဖတ်ခြင်း။

မည်သည့်စာဖတ်ခြင်းကိုမဆို checksum စစ်ဆေးခြင်းဖြင့် တွဲပေးပါသည်။
checksum မကိုက်ညီပါက၊ မှန်ကန်သောဒေတာကိုဖတ်ရန်မျှော်လင့်ချက်ဖြင့် အကြိမ်ပေါင်းများစွာ ထပ်ခါတလဲလဲဖတ်ရှုပါ။

(ဒါက အဓိပ္ပါယ်ရှိတယ်၊ Linux NOR Flash မှ ဖတ်မှုများကို ကက်ရှ်မလုပ်ပါ၊ အတည်ပြုပြီးဖြစ်သည်)

flash memory တွင် စာရေးခြင်း။

ကျွန်တော်တို့က အချက်အလက်တွေကို ချရေးတယ်။
အဲဒါတွေကို ဖတ်ကြည့်ရအောင်။

ဖတ်ပြီးသောဒေတာသည် ရေးထားသောဒေတာနှင့် မကိုက်ညီပါက၊ ကျွန်ုပ်တို့သည် ဧရိယာကို သုညဖြင့်ဖြည့်ပြီး အမှားတစ်ခုကို အချက်ပြပါသည်။

လည်ပတ်ရန်အတွက် microcircuit အသစ်ကို ပြင်ဆင်နေပါသည်။

အစပြုခြင်းအတွက်၊ ဗားရှင်း 1 ပါသော ခေါင်းစီးကို ပထမ (သို့မဟုတ် ထို့ထက်ပို၍ တိတိကျကျ၊ သုည) စာမျက်နှာသို့ ရေးထားသည်။
၎င်းနောက်တွင်၊ ကနဦးအကြောင်းအရာကို ဤစာမျက်နှာတွင် ရေးသားထားပါသည် (၎င်းတွင် စက်၏ UUID နှင့် ပုံသေဆက်တင်များပါရှိသည်)။

ဒါပဲ၊ flash memory က အလုပ်ဖြစ်နေပါပြီ။

စက်ကို တင်ပေးသည်။

တင်သည့်အခါ၊ စာမျက်နှာတစ်ခုစီ၏ ပထမဆုံး 8 bytes (ခေါင်းစီး + CRC) ကို ဖတ်ပြီး အမည်မသိ Magic နံပါတ် သို့မဟုတ် မမှန် CRC ပါသော စာမျက်နှာများကို လျစ်လျူရှုထားသည်။
"မှန်ကန်သော" စာမျက်နှာများမှ၊ အများဆုံးဗားရှင်းပါသော စာမျက်နှာများကို ရွေးချယ်ပြီး ၎င်းတို့ထဲမှ နံပါတ်အများဆုံးရှိသော စာမျက်နှာကို ယူသည်။
ပထမမှတ်တမ်းကို ဖတ်ပြီး CRC သည် မှန်ကန်မှုရှိမရှိ စစ်ဆေးပြီး "ဆက်စပ်မှု" အလံကို စစ်ဆေးထားသည်။ အားလုံးအဆင်ပြေပါက ဤစာမျက်နှာကို လက်ရှိအဖြစ် သတ်မှတ်သည်။ မဟုတ်ပါက "တိုက်ရိုက်" စာမျက်နှာကို ရှာမတွေ့မချင်း ယခင်စာမျက်နှာသို့ ပြန်လှည့်ပါ။
တွေ့ရှိသောစာမျက်နှာတွင် ကျွန်ုပ်တို့သည် “အကြောင်းအရာ” အလံဖြင့် ကျွန်ုပ်တို့အသုံးပြုသည့် မှတ်တမ်းများအားလုံးကို ဖတ်ပါသည်။
zlib အဘိဓာန်ကို သိမ်းဆည်းပါ (ဤစာမျက်နှာသို့ ထည့်ရန် လိုအပ်ပါမည်)။

ဒါပဲ၊ loading ပြီးသွားပြီ၊ context ကိုပြန်ယူ၊ သင်အလုပ်လုပ်နိုင်ပါတယ်။

မှတ်တမ်းတစ်ခုထည့်သွင်းခြင်း။

ကျွန်ုပ်တို့သည် Z_SYNC_FLUSH ကို သတ်မှတ်ပေးကာ မှန်ကန်သောအဘိဓာန်ဖြင့် မှတ်တမ်းကို ချုံ့ပါသည်။ ချုံ့ထားသော မှတ်တမ်းသည် လက်ရှိစာမျက်နှာနှင့် ကိုက်ညီမှုရှိမရှိကို ကျွန်ုပ်တို့ ကြည့်ရှုပါသည်။
အကယ်၍ ၎င်းသည် အဆင်မပြေပါက (သို့မဟုတ် စာမျက်နှာပေါ်တွင် CRC အမှားအယွင်းများရှိနေပါက) စာမျက်နှာအသစ်တစ်ခုစတင်ပါ (အောက်တွင်ကြည့်ပါ)။
ကျွန်တော်တို့ CRC နဲ့ မှတ်တမ်းရေးတယ်။ အမှားအယွင်းတစ်ခုဖြစ်ပေါ်ပါက ကျွန်ုပ်တို့သည် စာမျက်နှာအသစ်ကို စတင်သည်။

စာမျက်နှာအသစ်

အနိမ့်ဆုံးနံပါတ်ပါသော အခမဲ့စာမျက်နှာကို ကျွန်ုပ်တို့ ရွေးချယ်သည် (ကျွန်ုပ်တို့သည် ခေါင်းစီးတွင် မမှန်သော စစ်ဆေးမှုတစ်ခုပါသည့် စာမျက်နှာ သို့မဟုတ် လက်ရှိ အခမဲ့ဖြစ်နိုင်သော ဗားရှင်းထက်နိမ့်သော ဗားရှင်းဖြင့် စာမျက်နှာတစ်ခုကို ကျွန်ုပ်တို့ စဉ်းစားသည်)။ ထိုသို့သော စာမျက်နှာများ မရှိပါက၊ လက်ရှိ ဗားရှင်းနှင့် တူညီသော ဗားရှင်းရှိသည့် အနည်းဆုံး နံပါတ်ရှိသော စာမျက်နှာကို ကျွန်ုပ်တို့ ရွေးချယ်ပါသည်။
ရွေးချယ်ထားသော စာမျက်နှာကို ကျွန်ုပ်တို့ ဖျက်ပစ်ပါသည်။ အကြောင်းအရာများကို 0xff နှင့် နှိုင်းယှဉ်ပါသည်။ တစ်ခုခုမှားနေပါက၊ ကျွန်ုပ်တို့သည် နောက်စာမျက်နှာကို အခမဲ့ယူသည်၊ စသဖြင့်။
ကျွန်ုပ်တို့သည် ဖျက်ထားသောစာမျက်နှာသို့ ခေါင်းစီးကိုရေးသည်၊ ပထမ entry သည် အကြောင်းအရာ၏ လက်ရှိအခြေအနေဖြစ်ပြီး နောက်တစ်ခုသည် မရေးထားသော log entry (တစ်ခုရှိလျှင်) ဖြစ်သည်။

ဖော်မတ်၏ အသုံးချနိုင်မှု

ကျွန်ုပ်၏အမြင်အရ၊ ဤသည်မှာ NOR Flash တွင် ပိုနည်းသော အချက်အလက်စီးကြောင်းများ (ရိုးရိုးစာသား၊ JSON၊ MessagePack၊ CBOR၊ ဖြစ်နိုင်ခြေရှိသော protobuf) ကို သိမ်းဆည်းရန်အတွက် ကောင်းမွန်သောဖော်မတ်တစ်ခုဖြစ်သည်။

ဟုတ်ပါတယ်၊ ဖော်မတ်သည် SLC NOR Flash အတွက် "ချွန်ထက်သည်" ဖြစ်သည်။

၎င်းကို NAND သို့မဟုတ် MLC NOR ကဲ့သို့သော မြင့်မားသော BER မီဒီယာများတွင် အသုံးမပြုသင့်ပါ။ (ထိုကဲ့သို့သော memory သည် ရောင်းရန်ပင်ရှိပါသလား။ အမှားပြင်ကုဒ်များတွင် ၎င်းကို ဖော်ပြခြင်းများကိုသာ မြင်ဖူးသည်).

ထို့အပြင်၊ ၎င်းကို ၎င်းတို့၏ကိုယ်ပိုင် FTL ဖြစ်သည့် USB flash၊ SD၊ MicroSD စသည်တို့ပါရှိသည့် စက်များတွင် အသုံးမပြုသင့်ပါ။ (ထိုကဲ့သို့သောမမ်မိုရီအတွက် ကျွန်ုပ်သည် စာမျက်နှာအရွယ်အစား 512 bytes၊ စာမျက်နှာတစ်ခုစီ၏အစတွင် လက်မှတ်နှင့် ထူးခြားသောမှတ်တမ်းနံပါတ်များကို ဖော်မတ်ပြုလုပ်ခဲ့သည် - တစ်ခါတစ်ရံတွင် ဆက်တိုက်ဖတ်ရုံဖြင့် "ချို့ယွင်းနေသော" flash drive မှ အချက်အလက်အားလုံးကို ပြန်လည်ရယူနိုင်သည်).

အလုပ်များပေါ်မူတည်၍ 128Kbit (16Kb) မှ 1Gbit (128Mb) flash drive များတွင် ပြောင်းလဲမှုမရှိဘဲ ဖော်မတ်ကို အသုံးပြုနိုင်ပါသည်။ ဆန္ဒရှိပါက ၎င်းကို ပိုကြီးသည့် ချစ်ပ်များပေါ်တွင် သုံးနိုင်သော်လည်း စာမျက်နှာအရွယ်အစားကို ချိန်ညှိရန် လိုအပ်ပါသည်။ (ဒါပေမယ့် ဒီနေရာမှာ စီးပွားရေးဖြစ်နိုင်ခြေကို မေးစရာရှိလာပါတယ်၊ ထုထည်ကြီးမားတဲ့ NOR Flash ရဲ့စျေးနှုန်းက အားရစရာမရှိပါဘူး။).

တစ်ယောက်ယောက်က စိတ်ဝင်စားစရာကောင်းတဲ့ format ကိုတွေ့ပြီး open source ပရောဂျက်မှာ သုံးချင်ရင် ကျွန်တော့်ကို စာရေးပါ၊ အချိန်ရှာပါ၊ ကုဒ်ကို ဖျက်ပြီး github မှာ တင်လိုက်ပါ။

ကောက်ချက်

ကျွန်ုပ်တို့မြင်နိုင်သည်အတိုင်း၊ အဆုံးတွင် format သည်ရိုးရှင်းပါသည်။ ပျင်းစရာ ကောင်းတယ်။.

ဆောင်းပါးတစ်ပုဒ်တွင် ကျွန်ုပ်၏အမြင်၏ ဆင့်ကဲဖြစ်စဉ်ကို ထင်ဟပ်ရန် ခက်ခဲသော်လည်း ကျွန်ုပ်ကို ယုံကြည်ပါ- အစပိုင်းတွင် ကျွန်ုပ်သည် အနီးကပ် နျူကလီးယား ပေါက်ကွဲပြီးနောက်တွင်ပင် ရှင်သန်နိုင်သည့် ဆန်းပြားသော၊ ဖျက်ဆီး၍မရသော၊ ရှင်သန်နိုင်သည့် အရာတစ်ခုကို ဖန်တီးလိုပါသည်။ သို့သော်၊ အကြောင်းပြချက် (မျှော်လင့်ချက်) သည် အောင်မြင်နေဆဲဖြစ်ပြီး ဦးစားပေးအရာများသည် ရိုးရှင်းမှုနှင့် ကျစ်လစ်သိပ်သည်းမှုဆီသို့ တဖြည်းဖြည်း ပြောင်းလဲသွားခဲ့သည်။

အမှားလုပ်မိလို့ ဖြစ်မလား။ ဟုတ်ပါတယ်။ အရည်အသွေးနိမ့် မိုက်ခရိုစကွတ်အသုတ်များကို ဝယ်ယူခဲ့ခြင်း ဖြစ်နိုင်သည်။ သို့မဟုတ် အခြားသော အကြောင်းတစ်ခုခုကြောင့် စက်ပစ္စည်းသည် ယုံကြည်စိတ်ချရမှု သတ်မှတ်ချက်များနှင့် မကိုက်ညီပါ။

ဒီအတွက် ကျွန်တော့်မှာ အစီအစဉ်ရှိပါသလား။ ဆောင်းပါးကိုဖတ်ပြီးရင် အစီအစဉ်ရှိတယ်ဆိုတာ သံသယဖြစ်စရာ မလိုဘူးလို့ထင်ပါတယ်။ တစတစ တစငက ကက ကက က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က က

အနည်းငယ်ပိုလေးနက်စေရန်၊ ဖော်မတ်ကို အလုပ်ရွေးချယ်မှုအဖြစ်နှင့် "အစမ်းမီးပုံးပျံ" အဖြစ် နှစ်မျိုးလုံး ဖန်တီးခဲ့သည်။

လောလောဆယ်တွင်၊ အရာအားလုံးသည် စားပွဲပေါ်တွင် အဆင်ပြေနေပြီး၊ အဖြေကို ရက်အနည်းငယ်အတွင်း လက်တွေ့အသုံးချနိုင်မည်ဖြစ်သည်။ (ခန့်မှန်းခြေအားဖြင့်) စက်ပစ္စည်းတစ်ရာပေါ်တွင် "တိုက်ခိုက်ရေး" စစ်ဆင်ရေးတွင် ဘာဖြစ်မည်ကို ကြည့်ကြပါစို့ (ကံကောင်းထောက်မစွာ၊ ဖော်မတ်သည် ကျရှုံးမှုများကို ယုံကြည်စိတ်ချရသော ထောက်လှမ်းနိုင်စေရန် ခွင့်ပြုပေးသည်၊ ထို့ကြောင့် စာရင်းဇယားအပြည့်အစုံကို စုဆောင်းနိုင်လိမ့်မည်)။ လအနည်းငယ်အတွင်း ကောက်ချက်ဆွဲနိုင်မည်ဖြစ်သည်။ (သင်ကံမကောင်းပါက၊ စောစောကပင်).

၎င်းကိုအသုံးပြုပြီးနောက် ဆိုးရွားသောပြဿနာများကို ရှာဖွေတွေ့ရှိပြီး တိုးတက်မှုများ လိုအပ်ပါက၊ ကျွန်ုပ်သည် ၎င်းအကြောင်းကို ကျိန်းသေရေးသားပါမည်။

စာပေ

ရှည်လျားပြီး ငြီးငွေ့စရာကောင်းတဲ့ ကိုးကားမှုစာရင်းကို မဖန်တီးချင်ပါဘူး။ အားလုံးပဲ၊ လူတိုင်းမှာ Google ရှိတယ်။

ဤတွင် ကျွန်ုပ်အတွက် အထူးစိတ်ဝင်စားဖွယ်ကောင်းပုံရသော ရှာဖွေတွေ့ရှိမှုစာရင်းကို ချန်ထားရန် ဆုံးဖြတ်ခဲ့သည်၊ သို့သော် တဖြည်းဖြည်းနှင့် ၎င်းတို့သည် ဆောင်းပါး၏စာသားသို့ တိုက်ရိုက်ပြောင်းရွှေ့သွားပြီး စာရင်းထဲတွင် အကြောင်းအရာတစ်ခုသာ ကျန်ရှိတော့သည်-

1. အသုံးဝင်သည် infgen zlib ရေးသားသူထံမှ။ ၎င်းသည် deflate/zlib/gzip မော်ကွန်းတိုက်များ၏ အကြောင်းအရာများကို ရှင်းလင်းသောပုံစံဖြင့် ပြသနိုင်သည်။ deflate (သို့မဟုတ် gzip) ဖော်မတ်၏ အတွင်းပိုင်းဖွဲ့စည်းပုံနှင့် ကိုင်တွယ်ဖြေရှင်းရန် လိုအပ်ပါက၊ ၎င်းကို ကျွန်ုပ် အထူးအကြံပြုလိုပါသည်။

source: www.habr.com