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

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

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

ပြဿနာ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Linux kernel တွင်တည်ဆောက်ထားသော driver ကိုကျွန်ုပ်အသုံးပြုသည်၊ Raspberry တွင်၊ device tree 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 တွင် ခြေထောက် ၈ ချောင်းသာ ရှိသည်၊ ၎င်းတို့တွင် မြေ၊ ပါဝါ၊ SPI (CS, SI, SO, SCK၊ ); အဆင့်များသည် Raspberry Pi နှင့်တူညီသည်၊ နောက်ထပ်ဝါယာကြိုးများမလိုအပ်ပါ - ညွှန်ပြထားသော 8 pins ကိုချိတ်ဆက်ပါ။

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

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

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

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

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

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

ဒွိဒေတာ

ကဖြစ်
01010101

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

ဖြစ်လာသည်
00000101

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

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

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

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

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

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

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

စိတ်ကူးများ၊ ချဉ်းကပ်မှုများ၊ ထင်ဟပ်မှုများ

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

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

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

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

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

Compression overhead သည် အရေးမပါပါ (ကျွန်ုပ်တို့၏ပရိုဆက်ဆာသည် အလွန်အစွမ်းထက်ပါသည်၊ ပထမ Pi တွင် ကြိမ်နှုန်း 700 MHz ရှိသော core တစ်ခုရှိသည်၊ လက်ရှိမော်ဒယ်များတွင် ကြိမ်နှုန်း gigahertz ကျော်သော cores အများအပြားရှိသည်)၊ သိုလှောင်မှုနှင့်အတူ ငွေလဲနှုန်းသည် နိမ့်သည် (အများအပြား၊ megabytes per second) ၊ မှတ်တမ်းများ၏ အရွယ်အစားသည် သေးငယ်သည်။ ယေဘုယျအားဖြင့်၊ compression သည် စွမ်းဆောင်ရည်အပေါ် သက်ရောက်မှုရှိပါက၊ ၎င်းသည် အပြုသဘောသာဖြစ်သည်။ (လုံးဝကို နှိမ့်ချပြောဆိုခြင်းသာ). ထို့အပြင်၊ ကျွန်ုပ်တို့တွင် အမှန်တကယ် မြှပ်သွင်းထားခြင်း မရှိသော်လည်း ပုံမှန် Linux ဖြစ်သည် - ထို့ကြောင့် အကောင်အထည်ဖော်ရန် များစွာအားစိုက်ထုတ်ရန် မလိုအပ်ပါ (၎င်းသည် စာကြည့်တိုက်ကို လင့်ခ်ချိတ်ပြီး လုပ်ဆောင်ချက်များစွာကို အသုံးပြုရန် လုံလောက်သည်)။

မှတ်တမ်းတစ်ခုအား အလုပ်လုပ်သည့်စက်ပစ္စည်းတစ်ခုမှ (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 တွေကို Compressed အရမ်းကောင်းပါတယ်။
ထို့ကြောင့် (ကျွန်ုပ်တို့သည် ဆိုးရွားသော ချို့ယွင်းချက်များကို မတွေ့ပါက) ဖိသိပ်မှု ရှိလာပါမည်။ တူညီသော flash drive တွင်ဒေတာများပိုမိုရရှိနိုင်သောကြောင့်ဖြစ်သည်။

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

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

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

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

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

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

ဆောင်းပါးကိုအခြေခံ၍ ဒူးဆစ်စမ်းသပ်မှုတစ်ခုပြုလုပ်ခဲ့ပြီး စာမျက်နှာအရွယ်အစား 70Kb ရှိသော စက်ပစ္စည်းတစ်ခုမှ မှတ်တမ်းဝင်ရောက်မှု 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 ဖြစ်လိမ့်မည်။ ၎င်းတို့ကို သိပါက ၎င်းတို့ကို သိမ်းဆည်းရန် မလိုအပ်ပါ၊ ထို့ကြောင့် နောက်ဆုံးအရွယ်အစားမှာ 324Kb သာဖြစ်သည်။

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

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

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

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

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

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

ထို့ကြောင့်၊ စမ်းသပ်ဒေတာတွင်၊ အမှုကိစ္စများ၏ 100% တွင် 0x00၊ 0x00၊ 0xff၊ 0xff မတိုင်မီ သုညဘိုက်တစ်ခုရှိပြီး အမှုများ၏ သုံးပုံတစ်ပုံကျော်တွင် သုညဘိုက်နှစ်ခုရှိသည် (အမှန်က ကျွန်တော်သည် binary CBOR ကိုသုံး၍ စာသား JSON ကိုအသုံးပြုသည့်အခါ၊ အမျိုးအစား 2 - ရွေ့လျားပိတ်ဆို့သည့်တုံးများသည် ပို၍အဖြစ်များလိမ့်မည်၊ အသီးသီး၊ 0x00၊ 0x00၊ 0xff၊ 0xff မတိုင်မီ အပိုထပ်ဆောင်းသုညဘိုက်များမပါဘဲ ပိတ်ဆို့မှုများကို ကြုံတွေ့ရလိမ့်မည်).

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

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

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

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

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

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

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

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

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

Alas၊ FLUSH ဖြင့် ၎င်းသည် အလွန်ကောင်းမွန်စွာ မလုပ်ဆောင်နိုင်ခဲ့ပါ - ချုံ့ထားသောဒေတာအရွယ်အစားမှာ 700Kb ခန့်ရှိသည်။

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

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

သိမ်းဆည်းခြင်းဆိုင်ရာ ပြဿနာများသို့ ပြန်သွားကြပါစို့။

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

ဤပြဿနာကိုဖြေရှင်းရန် ချဉ်းကပ်နည်းတစ်ခုရှိသည်။

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

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

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

ချုံ့ထားသောပုံစံတွင် ကီလိုဘိုက်အနည်းငယ်ထက် ကြီးမားသောမှတ်တမ်းများကို ကျွန်ုပ်မျှော်လင့်မထားသော်လည်း 32Kb စာမျက်နှာများ (တစ်ချပ်လျှင် စုစုပေါင်း 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:

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

Option ကို 3:

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

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

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

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

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

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

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

ကျစ်လစ်မှု-

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

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

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

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

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

Write လုပ်ဆောင်ချက်များ၏ အောင်မြင်မှုကို စောင့်ကြည့်ရန် Bit Fields ကို အသုံးပြုခြင်း။

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ဒေတာ၊ ဘိုက်
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 များဖြင့် ပြဿနာတစ်ခုပေါ်လာသည်- ၎င်းတို့သည် single 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 အမှားအယွင်းများ (ကျွန်ုပ်တို့အတွက်လည်း ဖြစ်ရိုးဖြစ်စဉ်တစ်ခု) သို့မဟုတ် packet များပေါ်ရှိ ဘစ်အမှား 2 ခု သို့မဟုတ် ဂဏန်းအမှားများ သင့်လျော်သောအလျား။

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прочее

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

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

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

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

ဘိုက်အော်

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

Pagination

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

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

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

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

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

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

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

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

• two-byte Magic Number အကွက် (ဖော်မတ်ဗားရှင်း၏ လက္ခဏာတစ်ခုလည်း)
  ဖော်မတ်၏ လက်ရှိဗားရှင်းအတွက် ၎င်းကို တွက်ချက်သည်။ 0xed00 ⊕ номер страницы;
• နှစ်ဘိုက်တန်ပြန် “စာမျက်နှာဗားရှင်း” (မမ်မိုရီ သံသရာနံပါတ်)။

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

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

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

• မှတ်တမ်းအမျိုးအစားကို ညွှန်ပြသော one bit (T) - 0 - context, 1 - log;
• 1 မှ 7 bits အထိ ပြောင်းလဲနိုင်သော အရှည်အကွက် (S)၊
• မှတ်တမ်းအရှည် (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 သို့မရေးထားသော ချုံ့ထားသောဒေတာများ၏ နောက်ဆုံးဘိုက်များကို အနီရောင်ဖြင့်ဖော်ပြသည်။

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

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

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

ချက်ဆမ်ကို တိုက်ရိုက်လိုက်နာခြင်းသည် နောက်မှတ်တမ်း၏ ခေါင်းစီးဖြစ်သည်။

ခေါင်းစီးသည် ၎င်း၏ပထမဘိုက်အား 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 အဘိဓာန်ကို သိမ်းဆည်းပါ (ဤစာမျက်နှာသို့ ထည့်ရန်အတွက် လိုအပ်ပါမည်)။

ဒါပဲ၊ ဒေါင်းလုဒ်လုပ်ပြီးသွားပြီ၊ ဆက်စပ်မှုကို ပြန်လည်ရယူပြီး သင်အလုပ်လုပ်နိုင်ပါတယ်။

ဂျာနယ်ထည့်သွင်းခြင်း။

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

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

ကျွန်ုပ်တို့သည် အနိမ့်ဆုံးနံပါတ်ပါသော အခမဲ့စာမျက်နှာကို ရွေးချယ်သည် (ကျွန်ုပ်တို့သည် အခမဲ့စာမျက်နှာကို ခေါင်းစီးတွင် မမှန်ကန်သော checksum တစ်ခု သို့မဟုတ် လက်ရှိထက်နည်းသော ဗားရှင်းဖြင့် စာမျက်နှာတစ်ခုဟု ကျွန်ုပ်တို့ယူဆသည်)။ ထိုသို့သော စာမျက်နှာများ မရှိပါက၊ လက်ရှိ ဗားရှင်းနှင့် တူညီသော ဗားရှင်းရှိသည့် အနိမ့်ဆုံး နံပါတ်ရှိသော စာမျက်နှာကို ရွေးချယ်ပါ။
ရွေးချယ်ထားသော စာမျက်နှာကို ကျွန်ုပ်တို့ ဖျက်ပစ်ပါသည်။ အကြောင်းအရာများကို 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 ရဲ့ စျေးနှုန်းက အားရစရာမရှိပါဘူး။).

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

ကောက်ချက်

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

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

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

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

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

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

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

စာပေ

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

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

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

source: www.habr.com