Eelalugu

Meil on oma arendatud automaadid. Sees on Raspberry Pi ja mõningane lisaseade eraldi plaadil. Ühendatud on müntide vastuvõtja, pangakaarditud, pangaterminal jne. Kõike juhib omakäeliselt kirjutatud programm. Kõik tööajalugu salvestatakse USB-mälupulgale (MicroSD), mis edastatakse seejärel interneti kaudu (kasutades USB-modem) serverisse, kus see salvestatakse andmebaasi. Müügiteave laaditakse 1C-sse, samuti on olemas lihtne veebiliides jälgimiseks jne.

Seega on ajakiri hädavajalik – arvestuseks (seal on tulu, müügid jne), jälgimiseks (kõikvõimalikud tõrked ja muud ootamatud olukorrad); see on, võib öelda, kogu teave, mis meil selle automaadi kohta on.

Probleem

Mälupulgad on näidanud end väga ebastabiilsete seadmetena. Need riknevad üllataval määral. See põhjustab nii automaatide seiskumisi kui ka (kui mingil põhjusel ajakirja ei suudetud veebis edastada) andmete kaotust.

See on juba mitte esimene kogemus mälupulkade kasutamisel; eelmisel projektis oli üle saja seadme, kus ajalugu salvestati USB-mälupulkadel. Seal olid samuti usaldusprobleemid ja mõnikord tuli kuus välja vahetada kümneid. Proovisime erinevaid mälupulkasid, sealhulgas brändipulki SLC mäluga; jah, mõned mudelid on usaldusväärsemad kui teised, kuid mälupulkade vahetamine ei lahendanud probleemi kardinaalselt.

Tähelepanu! Pikem artikkel! Kui teid ei huvita 'miks', vaid ainult 'kuidas', võite kohe minna lõppu artiklist.

Lahendus

Esimene mõte: loobuda MicroSD-st, paigaldada näiteks SSD ja bootida sellest. Teoorias on see võimalik, võib-olla, kuid suhteliselt kallis ja mitte eriti usaldusväärne (lisandub USB-SATA adapter; ka odavate SSD-de rike on statistiliselt murettekitav).

USB HDD ei tundu samuti eriti atraktiivne lahendus.

Seetõttu jõudsime sellise lahenduseni: jätta bootimine MicroSD-st, kuid kasutada neid kirjutamisest koosnevas režiimis ja salvestada tööajalugu (ja muu konkreetse seadme jaoks unikaalne teave — seerianumber, sensorite kalibreerimine jne) kuskile mujale.

Read-only fail-safe teema Raspberry Pi jaoks on juba põhjalikult uuritud, ma ei hakka selles artiklis rakenduse üksikasjadele peatuma. (kuid kui huvi on — ehk kirjutan sellel teemal mini-artikli).. Üks asi, mida sooviksin märkida: nii isikliku kogemuse kui ka nende tagasiside põhjal, kes on juba rakendanud, on usaldusväärsuse kasu olemas. Jah, täielikult rikkeid vältida ei saa, kuid nende tekkimise sagedust on täiesti võimalik oluliselt vähendada. Ja ka kaardid muutuvad ühtseks, mis lihtsustab hooldustöötajate vahetust oluliselt.

Riistvara osa

Mälu tüübi valikuga ei olnud erilisi kahtlusi — NOR Flash.
Argumentide loetelu:

• Lihtne ühendamine (tavaliselt SPI buss, mille kasutamise kogemus on juba olemas, seega „riistvara“ probleeme ei ole oodata);
• naljakas hind;
• standardne tööprotokoll (rakendus on juba Linuxi tuumas olemas, soovi korral saab kasutada ka kolmanda osapoole lahendusi, mida samuti leidub, või isegi kirjutada enda, sest kõik on lihtne);
• usaldusväärsus ja ressursid:
  tüüpilisest andmelehtest: andmed säilivad 20 aastat, 100000 kustutust iga ploki jaoks;
  kolmandatest allikatest: äärmiselt madal BER, väidetakse, et vigade paranduskoodide vajadust ei ole. (mõnedes töödes käsitletakse ECC-d NOR-i jaoks, kuid enamasti mõeldakse siiski MLC NOR-i, küll aga on see võimalik).

Vaatame nõudeid mahu ja ressursi osas.

Tahame, et andmed säiliksid soovitud vähemalt paariks päevaks. See on vajalik selleks, et ajaloolised müügid ei kaoks, kui tekib mingit tüüpi suhtlusprobleeme. Suundume viiele päevale, selle ajaga (isegi puhkepäevade ja pühade arvestamisel) on probleem lahendatav.

Meil koguneb praegu päevas umbes 100 kb logi (3-4 tuhat kirjet), kuid see number kasvab järk-järgult – detailide suurenemise ja uute sündmuste lisandumise tõttu. Lisaks on aeg-ajalt ka tõususid (näiteks mõni andur hakkab valehäireid genereerima). Arvutame 10 tuhande kirje pealt, 100 baidi kohta - 1 megabait päevas.

Kokku tuleb 5 MB puhtaid (hästi tihendatavaid) andmeid. Nendele lisandub veel (karm hinnang) 1 MB administraatiivandmeid.

See tähendab, et vajame 8 MB kiipi, kui tihendamist ei kasutata, või 4 MB, kui kasutatakse. Need numbrid on täiesti realistlikud selle tüüpi mälu jaoks.

Ressursi osas: kui me eeldame, et mälu kirjutatakse täielikult üle mitte sagedamini kui iga 5 päeva tagant, siis 10-aastase kasutuse jooksul saame vähem kui tuhat üle kirjutamise tsüklit.
Tuletan meelde, et tootja lubab sada tuhat.

Veidi NOR vs NAND kohta

Praegu on kindlasti palju populaarsem NAND-mälu, kuid selle projekti puhul ei soovita ma seda kasutada: NAND, erinevalt NOR-ist, nõuab tingimata vigade paranduse koode, vigaste plokkide tabelit jne, ja NAND-kiipide jalgade arv on tavaliselt palju suurem.

NOR-i puudustena võib välja tuua:

• väike maht (ja seega kõrge hind megabaidi kohta);
• keskmine edastuskiirus (suures osas tänu sellele, et kasutatakse järjestikulist liidest, tavaliselt SPI või I2C);
• aeglane kustutamine (sõltuvalt ploki suurusest võib see võtta osahäälte sekunditest kuni mitme sekundini).

Dramatiseerimata, jätkame.

Kui üksikasjad huvitavad, on valitud kiip at25df321a (kuid siiski on see ebaoluline, turul on hulk analooge, mis on ühenduskaabli ja käsusüsteemiga ühilduvad; isegi kui soovime paigaldada kiibi teiselt tootjalt ja/või teises mahus, töötab kõik ilma koodi muutmiseta).

Kasutame Linuxi tuuma sisse ehitatud draiverit, Raspberryl on seadme puu katte toe tõttu kõik väga lihtne — piisab, kui panna /boot/overlaysse kompileeritud overlay ja veidi muuta /boot/config.txt faili.

DTS faili näidis

Olles aus, pole ma kindel, et see on kirjutatud ilma vigadeta, aga see töötab.

/*
 * 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?";
    };
};

Ja veel üks rida config.txt failis

dtoverlay=at25:spimaxfrequency=50000000

Kiibi ühendamise kirjeldust Raspberry Pi-le jätan vahele. Ühest küljest pole ma elektroonika spetsialist, teisest küljest on see isegi minu jaoks elementaarne: kiibil on ainult 8 jalga, millest me vajame vaid maapinda, toidet, SPI (CS, SI, SO, SCK); tasemed sobivad Raspberry Pi omadega, täiendavat sidumist ei ole vaja — lihtsalt ühendage kuus kontaktpunkti.

Ülesande seadmine

Nagu tavaliselt, läbib ülesande seadmine mitmeid iteratsioone, mulle tundub, et on aeg järgmise jaoks. Nii et lõpetame, koondame selle, mis on juba kirjutatud, ja selgitame välja varjatud üksikasjad.

Nii et, oleme otsustanud, et ajakiri salvestatakse SPI NOR Flash'i.

Mis on NOR Flash, kui keegi ei tea

See on energiat mittevajav mälu, millega saab teha kolme toimingut:

1. Lugemine:
   Tavaline lugemine: edastame aadressi ja loeme nii palju baitide, kui vajame;
2. Salvestamine:
   Kirjutamine NOR flash'i näeb välja nagu tavaline, kuid sellel on üks omadus: saab muuta ainult 1-ks 0, mitte vastupidi. Näiteks, kui meil on mälu lahtris 0x55, siis pärast 0x0f kirjutamist sinna, jääb seal hoitavaks 0x05 (vt tabelit allpool);
3. Kustutamine:
   Muidugi, peame suutma teha ka vastupidist operatsiooni — muuta 0-ks 1, selle jaoks ongi olemas kustutamise toiming. Erinevalt esimestest kahest toimingust, põhineb see blokki, mitte baitidel (valitud mikroskeemi minimaalne kustutus blokk on 4kb). Kustutamine hävitab kogu blokki tervikuna ja see on ainus viis, kuidas muuta 0-ks 1. Seetõttu tuleb flash-mäluga töötades sageli andmestruktuure joondada kustutusplokkide piirile.
   Kirjutamine NOR Flash'i:

Binaarsed andmed

Oli
01010101

Oleme kirjutanud
00001111

Kohandatud
00000101

Ajakiri ise on muutuva pikkusega kirjeid järjestus. Tüüpiline kirje pikkus on umbes 30 baiti (kuigi mõnikord juhtub, et kirjed on mitu kilobaiti pikad). Antud juhul töötame nendega lihtsalt kui baitide kogumiga, kuid kui huvitab, siis salvestustes kasutatakse CBOR-i.

Lisaks logile peame säilitama teatud „konfigureerimis” teavet, nii uuendatavat kui ka mitte: mingi seadme ID, andurite kalibreerimine, lipp „seade on ajutiselt välja lülitatud”, jne.
See teave koosneb key-value записidest, mis on samuti salvestatud CBOR-i. Meil ei ole seda teavet väga palju (maksimaalselt paar kilobaiti), see uuendatakse harva.
Hiljem nimetame seda kontekstiks.

Kui meenutada, kust see artikkel algas, on väga oluline tagada andmete säilitamise usaldusväärsus ja, kui võimalik, katkematu töö isegi riistvaraharvikute/debiitide korral.

Milliseid probleemiallikasid saaks kaaluda?

• Toitekatkestus kirjutamise-/kustutamisoperatsioonide ajal. See kuulub sellesse kategooriasse, et "lüli ei saa vastu võtta trikki".
  Teave pärit esitati stackexchange'is: toitekatkestuse ajal flash-mäluga töötamisel, kui toide katkeb, viib erase (1-seadistus) ja write (0-seadistus) määramatute käitumisteni: andmed võivad kirjutada, kirjutada osaliselt (ütleme, et edastasime 10 baiti/80 bitti, kuid suudame kirjutada ainult 45 bitti), ei ole välistatud, et osa bitte on "vaheolekus" (lugemine võib anda nii 0 kui ka 1);
• Flash-mälu enda vead.
  BER ehk väga madal, aga ei saa olla null;
• Vead bussil
  Andmed, mis edastatakse SPI kaudu, ei ole kuidagi kaitstud, võivad esineda nii üksikud bitti vead kui ka sünkroonimisvead — bitide kadumine või lisamine (mis viib massiliste andmete moonutusteni);
• Muud vead/tõrked
  Koodivead, Raspberry 'glitchid', tulnukate sekkumine...

Olen sõnastanud nõudmised, mille täitmine on minu arvates vajalik usaldusväärsuse tagamiseks:

• kirjutised peavad jõudma flash-mällu kohe, viivitusega kirjutamist ei arvestata; - kui viga tekib, peab see tuvastama ja töötlema võimalikult vara; - süsteem peab võimaluse korral taastama töö pärast vigade ilmnemist.
  (näide elust «kuidas mitte teha», millega arvan, et kõik on kokku puutunud: pärast hädaolukorra taaskäivitamist «hävis» failisüsteem ja operatsioonisüsteem ei käivitu)

Ideed, lähenemised, mõtisklused

Kui hakkasin sellele probleemile mõtlema, jooksid peast läbi hulgaliselt ideid, näiteks:

• kasutada andmete tihendamist;
• kasutada nutikaid andmestruktuure, näiteks hoida kirjepealkirjad eraldi kirjetest, et vigastuse korral mõnes kirjes saaks ülejäänud probleemideta lugeda;
• kasutada bitivälju kirje lõpetatuse kontrollimiseks toite katkestamise ajal;
• hoida kontrollsummasid kõikjal;
• kasutada mõnda sorti vigade parandamise kodeerimist.

Osa neist ideedest rakendati, osa otsustati kõrvale jätta. Alustame järjekorras.

Andmete tihendamine

Külastatud sündmused, mida me logime, on piisavalt ühtekuuluvad ja korduvad («viskasime mündi 5 rubla», «vajutasime tagastusnupu», …). Seetõttu peaks tihendamine olema piisavalt efektiivne.

Surve kulud kokkusurumise puhul on ebaolulised (meil on piisavalt võimas protsessor, isegi esimesel Pi-l oli üks 700 MHz tuum, tänapäevastes mudelites on mitu tuuma üle ühe gigaherti), andmete vahetamise kiirus salvestusega ei ole kõrge (mõned megabaitides sekundis), kirjete suurus on väike. Kokkuvõttes, kui kokkusurumine mõjutab jõudlust, siis ainult positiivselt. (absoluutselt mitte kriitiline, lihtsalt konstateerin). Pluss, meil ei ole ju tegelikult embedded, vaid tavaline Linux — seega ei tohiks rakendamine palju vaeva nõuda (piisab lihtsalt raamatukogu liitmisest ja mõne funktsiooni kasutamisest sealt).

Võeti proov logifailist töötavast seadmest (1,7 MB, 70 tuhat kirjet) ja alguses kontrolliti seda kokkusurumise osas olemasolevate gzipi, lz4, lzop, bzip2, xz ja zstd abil.

• gzip, xz, zstd näitasid sarnaseid tulemusi (40 KB).
  Üllatusena näitas moes xz end siin gzipi või zstd tasemel;
• lzip vaikeseadetega andis veidi halvemad tulemused;
• lz4 ja lzop näitasid mitte eriti häid tulemusi (150 KB);
• bzip2 näitas üllatavalt häid tulemusi (18 KB).

Seega andmed kokku surutakse väga hästi.
Seega (kui me ei leia tõsiseid vigu) on tihendamine vältimatu! Lihtsalt sellepärast, et sama mälupulgale mahub rohkem andmeid.

Mõtleme puudustele.

Esimene probleem: me oleme juba kokku leppinud, et iga kirje peab kohe mälupulgale minema. Tavaline arhiveerija kogub andmeid sisendvoolust, kuni otsustab, et on aeg kirjutada väljundisse. Meie peame kohe saama tihendatud andmeploki ja salvestama selle mittevolatile mällu.

Näen kolme teed:

1. Tihendada iga kirje sõnastiku tihendamise abil, selle asemel et kasutada eelnevalt arutatud algoritme.
   Töötav variant, kuid mulle see ei meeldi. Et tagada enam-vähem korralik tihendustase, peab sõnastik olema konkreetsete andmete jaoks "häälestatud"; iga muutus põhjustab, et tihendustase langeb katastroofiliselt. Jah, probleemi saab lahendada uue sõnastiku versiooni loomisega, kuid see on peavalu — meil tuleb hoida kõiki sõnastiku versioone; igas kirjes tuleb märkida, millise versiooniga sõnastik see oli tihendatud…
2. Tihendada iga kirje "klassikaliste" algoritmide abil, kuid sõltumatult teistest.
   Kasutatavad kokkusurumise algoritmid ei ole ette nähtud sellise suuruse (kümnete baitide) salvestuste töötlemiseks, kokkusurumise koefitsiendiks jääb selgelt alla 1 (st andmete maht suureneb hoopis, mitte ei vähene);
3. Teha FLUSH pärast iga salvestust.
   Paljudes kokkusurumisbiblioteekides on FLUSH-i tugi. See on käsk (või parameeter kokkusurumisprotseduurile), mille saanud, arhiivija loob kokkusurutud voogu nii, et selle alusel on võimalik taastada kõik dekompressitud andmed, mis on juba saadud. Selline analoog sync failisüsteemides või commit SQL-is.
   Oluline on, et hilisemad kokkusurumised saaksid kasutada akumuleeritud sõnastikku ja kokkusurumise aste ei kannataks nii palju kui eelmises variandis.

Mõtlen, et on ilmne, et valisin kolmanda variandi, peatume sellel lähemalt.

Leiti suurepärane artikkel FLUSH-ist zlib-is.

Tehtud inspiratsioonina artiklist katsetest, võtsin 70 tuhat logisaldot reaalsetelt seadmetelt, lehe suuruseks 60Kb (lehe suuruse juurde me veel tagasi tuleme) sain:

Algandmed
gzip kokkusurumine -9 (ilma FLUSH-ita)
zlib Z_PARTIAL_FLUSH-iga
zlib Z_SYNC_FLUSH-iga

Maht, Kb
1692
40
352
604

Esmapildist näib FLUSH hind ülemäära kõrge, kuid tegelikult on meie valik tagasihoidlik – kas mitte üldse kokku suruda või suruda (ja väga tõhusalt) FLUSH-iga. Ei tohi unustada, et meil on 70 000 kirjet, Z_PARTIAL_FLUSH toob kaasa vaid 4-5 baiti üleliigsust iga kirje kohta. Kompressioonikordaja osutus peaaegu 5:1, mis on suurepärane tulemus.

See võib tunduda üllatav, kuid tegelikult on Z_SYNC_FLUSH tõhusam viis FLUSH-i tegemiseks.

Kui kasutada Z_SYNC_FLUSH-i, siis iga kirje 4 viimast baiti on alati 0x00, 0x00, 0xff, 0xff. Ja kui need meile teada on – siis me ei pea neid säilitama, mis tähendab, et lõplik suurus on vaid 324Kb.

Viidatud artiklis on seletus:

Lisatakse tüüp 0 plokk, mille sisu on tühi.

Tüüp 0 plokk tühi sisu koosneb:

• kolmest bitist koosnev plokipealkiri;
• 0 kuni 7 bitti, mis on võrdsed nulliga, et saavutada baitide joondamine;
• neli baiti järjestus 00 00 FF FF.

Nagu ei ole raske märgata, eelviimasel plokil enne neid 4 baiti on 3 kuni 10 nullbitid. Kuid praktika on näidanud, et nullbitte on tegelikult vähemalt 10.

Selgub, et nii lühikesed andmeplokid kodeeritakse tavaliselt (kas alati?) ploki tüübiga 1 (fiksplokk), mis peab lõppema 7 nullbitiga, seega saame kokku 10-17 garanteeritud nullbitti (ja ülejäänud on tõenäoliselt nullid umbes 50% tõenäosusega).

Seega, testandmete puhul esinevad 100% juhtudest enne 0x00, 0x00, 0xff, 0xff üks nullbait, ja enam kui kolmandal juhul — kaks nullbait. (võib-olla on asi selles, et kasutan binaarset CBOR-i, ja teksti JSON-i kasutamisel esineks sagedamini 2. tüüpi blokke — dünaamiline plokk, seega esineks blokke ilma lisanduvate nullbaitideta enne 0x00, 0x00, 0xff, 0xff)..

Kokkuvõttes saab olemasolevate testandmete põhjal mahtuda alla 250 KB komprimeeritud andmeid.

Saame veel veidi kokku hoida, tegeledes bittide jongleerimisega: praegu ignoreerime bloki lõpus mitme nullbiti olemasolu, samuti ei muutu mõned bitid bloki alguses…
Aga siin tegin ma tahteotsuse lõpetada, muidu võiksin sellise tempoga enda arhivaatori arendamiseni jõuda.

Kokkuvõttes sain oma testandmetest 3–4 baiti salvestuse kohta, tihendamise suhe oli üle 6:1. Pean ausalt tunnistama, et ei oodanud sellist tulemust; minu arvates on kõik, mis on parem kui 2:1, juba tulemuseks, mis õigustab tihendamise kasutamist.

Kõik on suurepärane, kuid zlib (deflate) on siiski aegunud, väärikas ja veidi vanamoodne tihendamisalgoritm. Üksnes see, et sõnastikuks kasutatakse viimaseid 32 Kb tihendamata andmete voost, tundub tänapäeval kummaline (st kui mõni andmeplokk on väga sarnane sellele, mis oli sisendis 40 Kb tagasi, siis hakkab see uuesti arhiveerima, mitte ei viita eelmisele esinemisele). Moodsa arhiveerimise tarkvara puhul mõõdetakse sõnastiku suurust tihti megabaitides, mitte kilobaitides.

Nii et jätkame meie mini-uuringut arhiveerimiste kohta.

Järgmine proovitud oli bzip2 (meenutan, et ilma FLUSHita näitas see fantastilist tihendamise taset, peaaegu 100:1). Kahjuks FLUSHiga näitas see end väga halvasti, tihendatud andmete suurus osutus suuremaks kui tihendamata andmete suurus.

Minu oletused ebaedukuse põhjustest

Libbz2 pakub ainult ühte flush varianti, mis näib kustutavat sõnastiku (sarnane Z_FULL_FLUSH-ile zlib-s), peale selle on raske rääkida mingist tõhusast tihendamisest.

Viimaseks prooviti zstd. Sõltuvalt seadistustest suudab see tihendada kas gzip tasemel, kuid palju kiiremini, või isegi paremini kui gzip.

Kahjuks ei näidanud see koos FLUSH-iga end kuigi hästi: tihendatud andmete suuruseks tuli umbes 700 Kb.

Mina esitasin küsimuse projekti lehelt githubis ja sain vastuseks, et võiks arvestada umbes 10 baiti haldusteavet iga tihendatud andmeploki kohta, mis on lähedane saadud tulemusele, deflate’i ei suuda kuidagi jõuda.

Sellega otsustasin arhiivimise katsetega lõpetada (meeldetuletuseks, xz, lzip, lzo, lz4 ei näidanud end veel FLUSH-ita testimise etapis hästi, ja ma ei hakanud arvestama eksootilisemaid tihendusalgoritme).

Naaseme arhiivimise probleemide juurde.

Teine probleem (nagu öeldakse, järjekorra mõttes, mitte tähenduses) seisneb selles, et tihendatud andmed kujutavad endast ühtset voogu, kus pidevalt viidatakse varasematele osadele. Seega, kui mingi osa tihendatud andmetest saab kahjustada, kaotame mitte ainult sellega seotud mittetihendatud andmepaki, vaid ka kõik järgnevad.

Selle probleemi lahendamiseks on mitmeid lähenemisviise:

1. Probleemi ilmnemise ennetamine — lisada tihendatud andmetesse üleliigset teavet, mis võimaldab vigu tuvastada ja parandada; sellest räägime hiljem;
2. Minimeerida tagajärgi, kui probleem siiski tekib.
   Oleme varem rääkinud, et iga andmepaki saab tihendada iseseisvalt, sel juhul probleem ise kaob (ühe paketi andmete kahjustamine toob kaasa andmete kaotuse ainult selle paketi puhul). Kuid see on äärmuslik juhtum, kus andmete tihendamine on ebaefektiivne. Teine äärmus on kasutada kõiki 4 MB meie mikroskeemi üheks arhiiviks, mis annab meile suurepärase tihenduse, kuid katastroofilised tagajärjed andmete kahjustumise korral.
   Jah, usaldusväärsuse osas on vajalik kompromiss. Kuid tuleb meeles pidada, et arendame andmete salvestamise formaati energiaefektiivsel mälul, millel on äärmiselt madal BER ja deklareeritud andmete säilitamise aeg 20 aastat.

Katsete käigus avastasin, et märkimisväärsemad tihendustaseme kadumised algavad tihendatud andmeplokkide puhul, mille suurus on alla 10 Kb.
Varem mainiti, et kasutatav mälu on lehekülje struktuuriga, ma ei näe põhjust, miks ei peaks kasutama vastavust "üks leht - üks tihendatud andmeplokk".

See tähendab, et minimaalne mõistlik lehe suurus on 16 Kb (koos varuga teenindusteabe jaoks). Kuid nii väike lehe suurus seab olulisi piiranguid maksimaalse kirje suurusele.

Kuigi mul ei ole praegu ette nähtud kirjeid, mis ületaksid ühte kilobaiti tihendatud kujul, otsustasin kasutada lehti, mille suurus on 32 Kb (kokku saab 128 lehte kiibi kohta).

Kokkuvõte:

• Andmeid salvestame zlib (deflate) abil tihendatuna;
• Iga kirje puhul seadistame Z_SYNC_FLUSH;
• Iga tihendatud kirje lõpus kärpime viimased baitid (näiteks 0x00, 0x00, 0xff, 0xff); pealkirjas näitame, kui palju baite me eemaldame;
• Andmeid salvestatakse lehtedena, igaühes 32 Kb; lehe sees on pidev surve all olevate andmete voog; iga lehe surumist alustame uuesti.

Ja enne, kui lõpetame survet, soovin juhtida tähelepanu sellele, et meil on surutud andmeid vaid mõned bait kirje kohta, seega on äärmiselt oluline mitte paisutada teenindusteavet – iga bait on arvel.

Andmepealkirjade hoidmine

Kuna meil on muutliku pikkusega kirjed, peame kuidagi määrama asukoha/piirid.

Ma tean kolme lähenemist:

1. Kõik kirjed hoitakse pidevas voos, alguses on kirje pealkiri, mis sisaldab pikkust, ja seejärel tuleb ise kirje.
   Selles variandis võivad nii pealkirjad kui andmed olla muutliku pikkusega.
   Sisuliselt on meil ühekordne loend, mida kasutatakse laialdaselt;
2. Pealkirjad ja ise kirjed hoitakse eraldi voogudes.
   Kasutades püsiva pikkusega pealkirju, saavutame selle, et ühe pealkirja rike ei mõjuta teisi.
   Sarnast lähenemist kasutatakse näiteks paljudes failisüsteemides;
3. Kirjed säilitatakse pidevas voos, kirje piirid määratakse teatud märgise (sümboli/järjestuse, mis on andmeplokkides keelatud) järgi. Kui kirje sees on märk, asendame selle mingi järjestusega (põgenev).
   Sarnast lähenemist kasutatakse näiteks PPP protokollis.

Illustreerime.

Variant 1:

Siin on kõik väga lihtne: teades kirje pikkust, saame arvutada järgmise päise aadressi. Nii liigume päiste kaudu, kuni leiame ala, mis on täis 0xff (vabat ruumi) või lehe lõpu.

Variant 2:

Muutuva kirje pikkuse tõttu ei saa me ette öelda, kui palju kirjeid (ja seega ka päiseid) me lehele vajame. Päiseid ja andmeid saab jaotada erinevatele lehtedele, kuid mulle meeldib teine lähenemine: nii päised (püsiva suurusega) saavad olla lehe alguses kui ka andmed (muutva pikkusega) lehe lõpust. Niikaua, kuni nad "kohtuvad" (vaba ruumi ei jätku uue kirje jaoks), peame seda lehte täidetuks.

Variant 3:

Siin pole vaja pealkirjas salvestada andmete pikkust või muud asukoha teavet, piisab märkidest, mis tähistavad kirje piire. Kuid andmeid tuleb töötleda kirjutamisel / lugemisel.
Märgina võiksin kasutada 0xff (millega leht pärast kustutamist täidetakse), nii et vaba ala ei tõlgendataks andmetena.

Võrdlustabel:

Valik 1
Variant 2
Variant 3

Vigadele vastupidavus
—
+
+

Kompaktsus
+
—
+

Teostamise keerukus
*
**
**

Variant 1l on kriitiline puudus: kui mõni pealkiri on kahjustatud, hävitatakse kogu järgneva ahela. Ülejäänud variandid võimaldavad taastada osa andmeid isegi massiliste kahjustuste korral.
Siinkohal tasub aga meeles pidada, et otsustasime andmeid säilitada kompaktses vormis, seega kaotame me kõik andmed lehe peal pärast "katkist" salvestamist, nii et kuigi tabelis on miinus, ei arvestata seda.

Kompaktsus:

• esimeses variantis peame pealkirjas salvestama ainult pikkuse, kui kasutada muutuva pikkusega täisarve, siis enamikul juhtudel saame hakkama ühe baitiga.
• teises versioonis peame salvestama algse aadressi ja pikkuse; salvestus peab olema püsiva suurusega, hindan seda 4 baitiks salvestuse kohta (kaks baiti nihke jaoks ja kaks baiti pikkuse jaoks);
• kolmandale versioonile piisab vaid ühest tähest salvestuse alguse tähistamiseks, pluss ise salvestus kasvab tänu eskaleerimisele 1-2%. Üldiselt on see esimesega enam-vähem võrdsed.

Alguses pidasin teist versiooni põhiversiooniks (ja isegi kirjutasin rakenduse). Lõpetasin selle kasutamise vaid siis, kui otsustasin lõplikult kasutada kompressiooni.

Võib-olla kunagi kasutan sellist varianti. Näiteks, kui pean tegelema andmete salvestamisega laeva jaoks, mis käib Maa ja Marsi vahel — seal on nõuded usaldusväärsusele täiesti teisest tasemest, kosmiline kiirgus, …

Mis puutub kolmandasse versiooni: andsin sellele kaks tärni rakendamise keerukuse tõttu, lihtsalt seetõttu, et ma ei armasta tegeleda eskaleerimise, pikkuse muutmise jms. Jah, see võib olla kallutatud, kuid koodi pean kirjutama mina — miks sundida end tegema seda, mis ei meeldiv.

Kokkuvõte: valime salvestamisvariandi, kus kasutatakse ahelat „pealkiri muutujapikkusega andmete jaoks“, kuna see on tõhus ja lihtne rakendada.

Bitiväljade kasutamine kirjutamise operatsioonide eduka tulemuse jälgimiseks

Ma ei mäleta enam, kust ma selle idee sain, kuid see näeb välja enam-vähem nii:
Iga kirje jaoks eraldame mitu bitti lipu salvestamiseks.
Käesoleva räägitud juhendiga täidetakse kõik bitid pärast erase'it 1'ga, ja me saame muuta 1 0'ks, kuid mitte vastupidi. Seega kasutame „lipp pole seadistatud“ jaoks 1 ja „lipp seadistatud“ jaoks 0.

Nii võib välja näha muutuva pikkusega kirje salvestamine flash-mälus:

1. Seame lipu „kirje pikkuse salvestamine algas“;
2. Salvestame pikkuse;
3. Seame lipu „andmete salvestamine algas“;
4. Salvestame andmed;
5. Seame lipu „salvestamine lõppes“.

Lisaks on meil lipp „tõrge toimus“, kokku 4 bitilippu.

Sel juhul on meil kaks stabiilset olekut „1111“ — kirjutamine ei ole alanud ja „1000“ — kirjutamine läks edukalt; ettenägematu katkestuse korral saame vahepealsed olekud, mida saame hiljem tuvastada ja töödelda.

Lähtekoht on huvitav, kuid see kaitseb ainult ootamatute toitekatkestuste ja sarnaste rike eest, mis on loomulikult oluline, kuid see ei ole sugugi ainus (ja isegi mitte peamine) võimalike rikke põhjuste rühm.

Kokkuvõte: Liigume edasi head lahendust otsides.

Kontrollsummad

Kontrollsummad annavad samuti võimaluse veenduda (piisava tõenäosusega) selles, et loeme täpselt seda, mis oli kirjutatud. Ja erinevalt eespool käsitletud bitiväljadest töötavad need alati.

Kui vaatlen eeltoodud võimalike probleemiallikate loetelu, siis kontrollsummad suudavad tõdeda viga, sõltumata selle allikast. (v.a. võib-olla pahatahtlikud tulnukad — nemad võivad ka kontrollsummasid võltsida).

Nii et kui meie eesmärk on kontrollida, et andmed on terved, on kontrollsummad suurepärane idee.

Kontrollsummade arvutamise algoritmi valik ei tekitanud küsimusi — CRC. Ühelt poolt võimaldavad matemaatilised omadused 100%-liselt tuvastada teatud tüüpi vigu, teisest küljest näitab see algoritm juhuslike andmete puhul tavaliselt kokkulangevuste tõenäosust, mis ei ole oluliselt kõrgem teoreetilisest piirist. . Kuigi see ei ole kõige kiirem algoritm ega alati minimaalne kokkulangevuste arvu poolest, on sellel üks väga oluline omadus: testides, millega ma olen kokku puutunud, ei ole olnud mustreid, kus see selgelt ebaõnnestuks. Stabiilsus on antud juhul kõige olulisem omadus.

Mahuka uuringu näide: osa 1, osa 2 (linkid narod.ru, vabandust).

Siiski ei ole kontrollsumma valimise ülesanne veel lahendatud, CRC on terve kontrollsummade perekond. Tuleb otsustada pikkuse üle ja seejärel valida polüüm.

Kontrollsumma pikkuse valik ei ole nii lihtne küsimus, nagu see esmapilgul paistab.

Ilustreerin:
Oletame, et meil on vigade tõenäosus igas baitis ja ideaalne kontrollsumma, arvutame keskmise vigade arvu miljoni kirje kohta:

Andmed, bait
Kontrollsumma, bait
Unustatud vead
Valevea tuvastamised
Vale valeiduste kogus

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

Tundub lihtne – vali kontrollsummade pikkus vastavalt kaitstava teabe pikkusele, hoides valeandmete arvu miinimumis, ja asi on klaar.

Kuid lühikeste kontrollsummadega on probleem: need tuvastavad küll üksikuid bitivigu hästi, kuid võivad suure tõenäosusega aktsepteerida täiesti suvalisi andmeid õigetena. Habré oli juba artikel, mis käsitles probleemi reaalses elus.

Seetõttu, et kontrollsummade juhuslikku kokkulangemist praktiliselt vältida, tuleb kasutada vähemalt 32-bitiseid kontrollsummasid (pikkuste jaoks üle 64 bitti kasutatakse tavaliselt krüptograafilisi räsifunktsioone).

Kuigi olen varem öelnud, et ruumi tuleb hoida igas võimalikus viisis, kasutame siiski 32-bitist kontrollsummat (16 biti on liiga vähe, kokkulanguse tõenäosus on üle 0,01%; ja 24 bitti, nagu öeldakse, ei ole ei siia ega sinna).

Siin võib tekkida vastuväide: kas me ikka säästsime iga bait kompresseerimise valimisel, et nüüd kohe 4 baidi jagu andmeid anda? Kas ei oleks parem mitte kompresseerida ja mitte lisada kontrollsummat? Loomulikult mitte, kompressiooni puudumine ei tähenda, et me ei vaja terviklikkuse kontrolli.

Polünoomi valikul ei hakka me ratast uuesti leiutama, vaid võtame praegu populaarse CRC-32C.
See kood tuvastab 6 bitiviga pakettide puhul, mille pikkus on kuni 22 baiti (ilmselt kõige levinum juhtum meie jaoks), 4 bitiviga pakettide puhul pikkusega kuni 655 baiti (ka üsna tavaline meie seas), 2 või mis tahes paaritu arvu bitiviga pakettide puhul suvalise mõistliku pikkusega.

Kui kedagi huvitavad üksikasjad

Wikipediast leiate artikkli CRC-st.

CRC-32C koodiparameetrid järgnevaga Kopmani saidil – ilmselt maailma juhtiv ekspert CRC alal.

V tema artiklis has veel üks huvitav kood, mis tagab pisut paremad parameetrid meie jaoks asjakohaste pikkade pakettide jaoks, kuid ma ei pea vahet tähtsaks ja arvan end piisavalt pädevaks, et valida kohandatud kood standardse ja hästi uuritud koodi asemel.

Veelgi enam, kuna meie andmed on kokku pressitud, tekib küsimus: arvutada kontrollsumma pressitud või dekompressitud andmete põhjal?

Argumentid, miks kasutada kontrollsummat tihendamata andmete puhul:

• me peame lõpuks kontrollima andmete säilitamise korrektsust — just seda me otse kontrollime (samuti kontrollitakse võimalikke vigu tihendamise/dekompressiooni teostuses, kahjustusi, mis on põhjustatud samuti mälu vigadest jne);
• algoritm deflate zlib'is on piisavalt küps ja ei tohiks kukku, kui sisendandmed on «vales» vormis; rohkemgi veel, sageli suudab ta iseseisvalt tuvastada sisendvoos esinevad vead, vähendades seeläbi üleüldist vea avastamise tõenäosust (ma tegin testi ühes bitti pöörates lühikeses kirjes, zlib tuvastas vea umbes kolmandikul juhtudest).

Argumentid, miks mitte kasutada kontrollsummat tihendamata andmete puhul:

• CRC on loodud just väheste bittide vigade jaoks, mis on iseloomulikud flash-mälule (bittide viga tihendatud voos võib põhjustada massilist muutumist väljundvoos, kus me teoreetiliselt saame «kinni püüda» kokkulangevuse);
• mulle ei meeldi see mõte, et anda dekompressorile potentsiaalselt vigaseid andmeid, kes teab, kuidas ta reageerib.

Selles projektis otsustasin ma kõrvale hiilida üldiselt aktsepteeritud praktikast, mille kohaselt säilitatakse kontrollsummad kokku surutud andmete suhtes.

Kokkuvõte: kasutame CRC-32C, kontrollsummat arvutame andmete põhjal sellises vormis, nagu need kirjutatakse flash-mäele (pärast tihendamist).

Üksikasjalikkus

Liigne kodeerimine ei suuda muidugi täielikult välistada andmete kadumise, kuid see võib oluliselt (tihti palju korda) vähendada taastamatute andmekao tõenäosust.

Saame kasutada erinevaid liigsuse vorme, et vigu parandada.
Hammingi koodid suudavad parandada üksikute bitivigu, Reed-Solomoni koodid on sümboolsed, mitmed andmekoopiad koos kontrollsummadega või sellised kodeerimised nagu RAID-6 võivad aidata andmeid taastada isegi massiliste kahjustuste korral.
Alguses olin ma kaldunud kasutama laialdaselt vigadele vastupanuvates kodeeringutes, kuid siis sain aru, et kõigepealt tuleb mõista, milliste vigade eest me tahame end kaitsta, ja seejärel valida kodeerimine.

Oleme varem rääkinud, et vigu tuleb tuvastada võimalikult kiiresti. Millistel hetkedel võime vigadega silmitsi seista?

1. Katkestatud salvestus (mingil põhjusel katkestas toiteallikas salvestamise, Raspberry hangus, ...)
   Kahjuks ei jää sellise vea korral muud üle, kui eirata mittesobivaid salvestusi ja pidada andmeid kadunuks;
2. Salvestusvead (mingil põhjusel salvestati välkmälusse mitte see, mis oli salvestatud)
   Selliseid vigu saame kohe tuvastada, kui teeme pärast salvestamist kontrollimise;
3. Andmete moonutamine mälus säilitamise käigus;
4. Lugemisvead
   Vea parandamiseks piisab juhtumite korral, kus kontrollsummad ei kattu, lugemise kordamisest mitu korda.

See tähendab, et ainult kolmanda tüübi vead (andmete juhuslik riknemine säilitamise ajal) ei saa olla parandatud ilma vigadele vastupidava kodeerimiseta. Tundub, et sellised vead on siiski äärmiselt ebatõenäolised.

Kokkuvõte: Otsustati loobuda liigsest kodeerimisest, kuid kui kasutus tõestab, et see otsus on vale, naeratame selle küsimuse juurde tagasi (koos juba kogutud statistika rikkumistest, mis võimaldab valida parima kodeerimise variandi).

Muud

Muidugi ei võimalda artikli formaat põhjendada iga bitti formaadis. (ja mul on juba jõud otsas), seega lähen kiiresti üle mõningatele punktidele, millest varem ei räägitud.

• Otsustasin teha kõik lehed „võrdsed“
  See tähendab, et ei tule mingisuguseid spetsiaalseid lehti metaandmete, eraldiseisvate voogude jne jaoks; selle asemel on üksainus voog, mis kirjutab kõik lehed järjest.
  See tagab lehtede ühtlase kulumise, puudumise ainsast rikkepunktist ning lihtsalt meeldib;
• Kindlasti tuleb arvestada formaadi versioonidega.
  Formaadi versiooninumbrita päises on kurjast!
  Piisab, kui lisada lehe päisesse väli koos mingi Magic Number'iga (signatuur), mis näitab kasutatavat formaadi versiooni (ma ei arva, et neid praktiliselt rohkem kui tosin oleks);
• Kasutada kirjete jaoks (mida on väga palju) muutliku pikkusega pealkirju, püüdes enamikus juhtudest hoida nende pikkus 1 bait;
• Pealkirja pikkuse ja kärpimise osa pikkuse kodeerimiseks kasutada muutliku pikkusega binaarkoodisid.

Oli väga abiks veebigeneraator Huffman’i koode. Ainus minutitega suutsime leida vajalikud muutliku pikkusega koodid.

Andmete salvestamise formaadi kirjeldus

Baiti järjekord

Väljad, mille suurus ületab ühe bait, salvestatakse big-endian formaadis (võrgubaiti järjekord), st 0x1234 salvestatakse kui 0x12, 0x34.

Lehekülgede jagamine

Kõik välkmälu on jagatud võrdse suurusega lehekesteks.

Lehekese vaikimisi suurus on 32KB, kuid mitte rohkem kui 1/4 kogu mälukiibi suurusest (4MB kiibi puhul on see 128 lehekest).

Iga lehekülg salvestab andmeid sõltumatult teistest (tühikud ühe lehekülje andmed ei viita teistele lehekülgede andmetele).

Kõik leheküljed on nummerdatud loomulikus järjekorras (aadresside tõusvas järjekorras), alustades numbrist 0 (null lehekülg algab aadressilt 0, esimene 32KB-lt, teine 64KB-lt jne).

Mälukiipi kasutatakse tsüklilise pubufferina (ringbuffer), st alguses salvestamine toimub leheküljel numbriga 0, seejärel numbriga 1, … kui täidame viimase lehekülje, algab uus tsükkel ja salvestamine jätkub null leheküljelt.

Lehekülje sees

Lehekülje alguses on 4-baitine lehekülje pealkiri, seejärel pealkirja kontrollsummat (CRC-32C), edasi on salvestatud kirjed formaadis 'pealkiri, andmed, kontrollsumma'.

Lehe pealkiri (roheline-baar) koosneb:

• kahebytesest Magic Number (see on ka formaadi versiooni tähis)
  praeguse formaadi versioon on defineeritud kui 0xed00 ⊕ lehe number;
• kahebytesest arvestit 'Lehe versioon' (mälu kirjutustsükli number).

Lehe kirjeldused on salvestatud kompressioonivormingus (kasutatakse deflate algoritmi). Kõik kirjeldused ühel lehel kompressitakse ühes voos (kasutatakse ühte üldist sõnastikku), iga uue lehe puhul algab kompressioon uuesti. Seega, et dekompressida mistahes kirje, on vajalikud kõik varasemad kirjed sellest lehelt (ja ainult sellest).

Iga kirje kompressitakse Z_SYNC_FLUSH lipuga, mille tulemusena kompressioonivoo lõppu satub 4 baiti 0x00, 0x00, 0xff, 0xff, millele võivad eelnevalt järgneb ühe või kahe null-bait.
See järjekord (pikkusega 4, 5 või 6 bitti) eemaldatakse meeldejätmise ajal.

Kirje pealkiri koosneb 1, 2 või 3 baitist, mis sisaldavad:

• üht bitti (T), mis näitab kirje tüüpi: 0 — kontekst, 1 — ajakiri;
• muutuva pikkusega väli (S) vahemikus 1 kuni 7 bitti, mis määrab pealkirja pikkuse ja 'saba', mille tuleb paigaldada kirjele dekompressimiseks;
• kirje pikkus (L).

S väärtuste tabel:

S
Pealkirja pikkus, baitides
Kirjutamisel jäetakse kõrvale, baitides

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)

Püüdsin illustreerida, ei tea, kui selgelt see välja tuli:

Kollasega on tähistatud T väli, valgega S väli, rohelisega L (kompressitud andmete pikkus baitides), sinisega kompressitud andmed, punasega lõppbaitide kompressitud andmetest, mida ei kirjutata välkmällu.

Seega saame enim levinud pikkusega kirjeid (kuni 63+5 baiti kompressitud kujul) kirjutada ühe baitiga.

Iga kirje järel hoitakse CRC-32C kontrollsummat, mille algväärtusena (init) kasutatakse eelneva kontrollsummat pöördväärtust.

CRC-l on omadus «kestvus», see töötab (pluss-miinus bitide pööramine protsessi käigus) järgmiseks valemiks: .
Ehk tegelikult arvutame CRC kõigist eelnevatest baitidest pealkirjades ja andmetes sellel lehel.

Otse kontrollsummast järgneb järgmise kirje pealkiri.

Pealkiri on konstrueeritud nii, et selle esimene bait oleks alati erinev 0x00-st ja 0xff-st (kui pealkirja esimene bait on 0xff, tähendab see, et see on praegu kasutamata ala; 0x00 signaalib viga).

Umbes algoritmid

Lugemine flash-mälust

Iga lugemine toimub kontrollsummaga.
Kui kontrollsumma ei ühti – loetakse andmeid mitu korda, lootes siiski õigeid andmeid lugeda.

(see on mõttekas, Linux ei määra NOR Flash'i lugemise vahemälu, on tõestatud)

Kirjutamine flash-mällu

Kirjutame andmed.
Lugeme need.

Kui loetud andmed ei ühti kirjutatud andmetega – täidame ala nullidega ja signaalime vea.

Uue mikroskeemi tööks ettevalmistamine

Initsialiseerimiseks kirjutatakse esimese (tegelikult nullenda) lehekülje algusse pealkiri versiooniga 1.
Pärast seda kirjutatakse sellesse lehekülge algne kontekst (sisaldab automaadi UUID-d ja vaikeseadeid).

Kõik, flash-mälu on tööks valmis.

Automaatlaadimine

Laadimise ajal loetakse iga lehe esimesed 8 baiti (pealkiri + CRC), leheküljed, millel on tundmatu Magic Number või vale CRC, jäetakse tähelepanuta.
Valitud „õigest” leheküljest valitakse leheküljed, mille versioon on maksimaalne, ning sealt võetakse lehekülg, mille number on kõige suurem.
Loeme esimese kirje, kontrollime CRC korrektsetsust, konteksti lipu olemasolu. Kui kõik on korras, loeme selle lehe praeguseks. Kui ei, siis pöördume tagasi eelmisele lehele, kuni leiame „elava” lehe.
Leitud lehelt loeme kõik kirjed, need, millel on konteksti lipp, rakendame.
Salvestame zlib sõnastiku (see on vajalik selle lehe täiendamiseks).

Kõik, laadimine on lõpetatud, kontekst on taastatud, nüüd saab töötada.

Kirje lisamine ajakirja

Surume kirje kokku õigete sõnastikuga, kasutades Z_SYNC_FLUSH. Kontrollime, kas kokkusurutud kirje mahub当前頁.
Kui see ei mahutu (või lehel olid CRC vead), alustame uut lehte (vt allpool).
Kandke kirje ja CRC. Kui juhtub viga, alustame uut lehte.

Uus leht

Valime vabade lehtede hulgast väikseima numbri (vaba leht on see, mille pealkirjas on vale kontrollsumm ja mille versioon on väiksem kui praegune). Kui selliseid lehti pole, valime lehe, mille number on väikseim nendest, mille versioon on sama mis praegune.
Teeme valitud lehe erase. Kontrollime sisu 0xff-ga. Kui midagi on valesti, võtame järgmise vaba lehe jne.
Kustutatud lehe peale kirjutame pealkirja, esimeseks kirje on praegune konteksti seisund ja järgmiseks - kui see olemas, siis kirjutamata logikiri.

Formaatide rakendatavus

Minu arvates on see hea formaat igasuguste rohkem-vähem kokkutõmmatavate info voogude (lihtne tekst, JSON, MessagePack, CBOR, võib-olla protobuf) talletamiseks NOR Flashis.

Tõepoolest, formaat on kohandatud SLC NOR Flashi jaoks.

Seda ei tasu kasutada kõrge BER-iga meediate peal, nagu NAND või MLC NOR. (Kas selline mälu on üldse müügil? Olen kohanud viiteid ainult paranduskoode käsitlevates töödes.).

Veel enam, seda ei tasu kasutada seadmete puhul, millel on oma FTL: USB flash, SD, MicroSD jne. (sellise mälu jaoks tegin lehe formaadi 512 baitiga, lehtede alguses oleva allkirja ja ainulaadsete kirje numbritega — mõnikord suutsin „kinnise” mälupulga lihtsa järjestikuse lugemisega kõik andmed taastada).

Sõltuvalt ülesannetest saab formaati ilma muudatusteta kasutada mälupulkadel alates 128 Kb (16 Kb) kuni 1 Gb (128 Mb). Soovi korral saab seda kasutada ka suuremate mahutavustega kiipidel, kuid tõenäoliselt tuleb kohandada lehe suurust. (Aga siin tuleb juba mängu majanduslik otstarbekus, NOR Flash suure mahutavusega hind ei rõõmusta).

Kui keegi leiab formaadi huvitavaks ja soovib seda kasutada avatud projektis — kirjutage, püüan leida aega koodi korrastamiseks ja githubi üleslaadimiseks.

Kokkuvõte

Nagu näha, on formaadist lõpuks saanud lihtne ja isegi igav.

Artiklis on keeruline peegeldada oma vaatepunkti evolutsiooni, kuid uskuge: algselt tahtsin luua midagi keerulist, purunematut, mis suudaks ellu jääda isegi tuumaplahvatuse läheduses. Kuid mõistus (loodan) võitis ja järk-järgult nihkusid prioriteedid lihtsuse ja kompaktsuse suunas.

Kas on võimalik, et ma eksisin? Jah, muidugi. On täiesti võimalik, et oleme ostnud partiid ebakvaliteetseid mikroskeeme. Või mõnel muul põhjusel ei vasta seadmed usaldusväärsuse ootustele.

Kas mul on selleks juhtumiks plaan? Ma arvan, et artiklit lugedes ei kahtle sa, et plaan on olemas. Ja isegi mitte üks.

Kui öelda tõsisemalt, siis formaat on loodud samal ajal nii tööversiooniks kui ka katsetuseks.

Praegu töötab laual kõik normaalselt, sõna otseses mõttes paar päeva tagasi alustatakse lahenduse rakendamist. (umbes) sajale seadmele, vaatame, mis juhtub "päris" kasutuses (õnneks, loodan, et formaat võimaldab usaldusväärselt tuvastada tõrkeid; nii et saame koguda põhjalikku statistikat). Mõne kuu pärast saab järeldusi teha. (ja kui ei vea, siis ka varem).

Kui kasutamise tulemusena tuvastatakse tõsised probleemid ja on vaja täiendusi, siis kindlasti kirjutan sellest.

Kirjandus

Ei tahtnud koostada pikka tüütut loetelu kasutatud töödest, lõpuks on kõigil ju Google olemas.

Siin otsustasin jätta nimekirja leidudest, mis tundusid mulle eriti huvitavad, kuid järk-järgult on need otseselt artikli teksti üle kandunud ning nimekirjas on jäänud vaid üks punkt:

1. Tööriist infgen autorilt zlib. Suudab selgelt kuvada deflate/zlib/gzip arhiivide sisu. Kui peate tegelema deflate (või gzip) formaadi sisemise struktuuri mõistmisega, siis soovitan tungivalt.

Allikas: habr.com