Eellugu

Meil on oma arendatud müügiautomaadid. Sees on Raspberry Pi ja veidi lisaplaati. Ühendatud on mündiproovija, pangakaardilugeja… Kõike haldab ise kirjutatud programm. Kogu töö ajalugu salvestatakse flash-mälupessa (MicroSD), mis edastatakse seejärel interneti kaudu (USB-modemi abil) serverisse, kus see säilitatakse andmebaasis. Müügiteave laaditakse 1C-sse, samuti on olemas lihtne veebiliides jälgimiseks jne.

See tähendab, et ajakiri on eluliselt vajalik - arvestamiseks (seal on tulu, müügid jms), jälgimiseks (kõiksugu tõrked ja muud eriolukorrad); see on, võiks öelda, kogu teave, mis meil selle automaadi kohta on.

Probleem

Flash-mälud osutuvad väga ebakindlateks seadmeteks. Need riknevad üpris regulaarselt. See toob kaasa nii automaatide seiskumisi kui ka (kui mingil põhjusel ei saanud ajakirja online edastada) andmete kadumise.

See ei ole esimene kogemus flash-mälude kasutamisest, enne seda oli teistsugune projekt, kus oli rohkem kui sada seadet, kus ajalugu hoiti USB-flash-mäludel, seal olid samuti usaldusväärsuse probleemid, mõnikord oli kuu jooksul riknenud mälude arv kümnetes. Proovisime erinevaid flash-mälusid, sealhulgas ka SLC mäluga bränditud, jah, mõned mudelid on usaldusväärsemad kui teised, kuid flash-mälude vahetamine ei lahendanud probleemi kardinaalselt.

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

Lahendus

Esimene mõte, mis tuleb meelde: loobuda MicroSD-st, panna näiteks SSD ja laadida sealt. Teoreetiliselt on see võib-olla võimalik, kuid suhteliselt kallis ja mitte väga usaldusväärne (lisandub USB-SATA adapter; odavate SSD-de riketestatistika ei ole samuti julgustav).

USB HDD ei tundu samuti eriti atraktiivne lahendus.

Seetõttu jõudsime sellise variandini: jätta laadimine MicroSD-lt, kuid kasutada neid read-only režiimis, ning töö ajalugu (ja muu konkreetse seadme jaoks unikaalne teave - seerianumber, sensorite kalibreerimine jne) hoida kuskil mujal.

Read-only failisüsteemide teema Raspberry Pi jaoks on juba põhjalikult uuritud, ma ei hakka selle artikli raames detailidele peatuma. (kuid kui huvi on - võib-olla kirjutan selle teema kohta mini-artikli). Ainuke punkt, mida tahaksin märkida: nii isikliku kogemuse kui ka juba rakendanud tagasiside põhjal on paranduste usaldusväärsuses olemas. Jah, täielikult rikete eest pääseda ei saa, kuid nende sagedust on täiesti reaalne oluliselt vähendada. Ja ka kaartide vormingud muutuvad ühtseks, mis muudab teenindava personali asenduse oluliselt lihtsamaks.

Riistvara

Mälu tüübi valik ei tekitanud erilisi kahtlusi — NOR Flash.
Argumentid:

• lihtne ühendamine (enamasti SPI buss, mille kasutamise kogemus on juba olemas, nii et „rauda” probleeme ei paista tulevat);
• naljakas hind;
• standardne tööprotokoll (rakendus on juba Linuxi tuumas olemas, soovi korral võib võtta ka kolmanda osapoole lahenduse, mida on samuti saadaval, või isegi kirjutada oma, hea, et kõik on lihtne);
• usaldusväärsus ja ressurss:
  tüüpilisest andmelehelt: andmed säilitab 20 aastat, 100000 kustutamistsüklit iga bloki kohta;
  välistest allikatest: äärmiselt madal BER, väidetakse, et vea parandamise koodide vajadust ei ole (mõnedes teadustes käsitletakse ECC-d NOR-i jaoks, kuid tavaliselt peetakse seal silmas MLC NOR-i, nii et selline asi juhtub ka).

Hinnatakse nõudeid mahu ja ressursi osas.

Soov on, et andmed säilitaksid garantii korral mitu päeva. See on vajalik selleks, et igasuguste sideprobleemide korral ei kaoks müügihaja ajalugu. Suundume 5 päeva poole, mille jooksul (isegi arvestades nädalavahetusi ja pühi) probleemi lahendada.

Meil koguneb nüüd ööpäevas umbes 100 kb logi (3-4 tuhat kirje), kuid järk-järgult see number kasvab — detailide arv suureneb, lisanduvad uued sündmused. Lisaks esinevad mõnikord puhangud (mõni sensor hakkab valehäiretega spammima, näiteks). Arvestagem 10 tuhande kirje peale 100 baiti — megabait päevas.

Seega tuleb kokku 5 MB puhast (hästi pigistatavat) andmeid. Nendele veel (harjumuspärane hinnang) 1 MB teenindusandmeid.

Seda silmas pidades on meie vajadus mikroskeemi järele 8 MB, kui me ei kasuta kokkusurumist, või 4 MB, kui me seda teeme. Need on täiesti reaalsed numbrid selle tüüpi mälu jaoks.

Mida ressurssi puutub: kui planeerime, et mälu kirjutatakse täielikult üle mitte sagedamini kui iga 5 päeva tagant, siis 10-aastase teenuse jooksul saame vähem kui tuhat üle kirjutamise tsüklit.
Tuletan meelde, et tootja lubab sada tuhat.

Veidi NOR vs NAND-ist

Täna on muidugi NAND mälu tunduvalt populaarsem, kuid selle projekti jaoks ma seda kasutada ei soovitaks: NAND, erinevalt NORist, nõuab kindlasti vigade parandamise koode, rikkeplokkide tabeleid jne., ja NAND mikrokiipide jalgade arv on tavaliselt samuti suurem.

NORi puuduseks võib märkida:

• väike maht (ja seega kõrge hind megabaiti kohta);
• madal edastuskiirus (peamiselt seetõttu, et kasutatakse järjestikku liidest, tavaliselt SPI või I2C);
• aeglane kustutamine (sõltuvalt ploki suurusest võtab see mõnest osast sekundist kuni mitme sekundini).

Tundub, et miski pole kriitiline, nii et jätkame.

Kui detailid huvitavad, on valitud mikrokiip at25df321a (kuigi see ei oma suurt tähtsust, on turul palju analooge, mis on ühenduste ja käskude osas ühilduvad; isegi kui tahame kasutada teise tootja mikrokiipi ja/või teise mahtu, töötab see koodi muutmata).

Kasutangi Linuxi tuuma sisse ehitatud draiverit, Raspberryl, tänu seadmepuu overlaytoetusele, on kõik väga lihtne — tuleb panna /boot/overlaysse kompileeritud overlay ja teha veidi muudatusi /boot/config.txt.

Näide dts failist

Austusega öeldes ei ole ma kindel, et see on kirjutatud vigadeta, kuid 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-s

dtoverlay=at25:spimaxfrequency=50000000

Mikrokiibi ühendamise kirjelduse vahele jätan. Ühest küljest ei ole ma elektroonika spetsialist, teisest küljest on see minu jaoks isegi liiga lihtne: mikrokiibil on vaid 8 jalga, millest me vajame maapinda, toiteallikat ja SPI-d (CS, SI, SO, SCK); tasemed kattuvad Raspberry Pi omadega, täiendavat toitekaablit ei ole vaja — lihtsalt ühendage kuus mainitud kontakti.

Ülesande seadmine

Nagu tavaliselt, läbib ülesande seadmine mitu iteratsiooni, ma arvan, et on aeg järgmise jaoks. Nii et peatugem, kogume kokku selle, mis on juba kirjutatud, ja selgitame välja varjatud detailid.

Nii oleme otsustanud, et ajakiri hoitakse SPI NOR Flashis.

Mis on NOR Flash, neile, kes ei tea

See on energiateadlik mälu, millega saab teha kolme operatsiooni:

1. Lugemine:
   Tavaline lugemine: edastame aadressi ja loeme nii palju baite, kui vajame;
2. Salvestamine:
   NOR flash'i kirjutamine näib olevat tavaline, kuid sel on üks eripära: saab ainult muuta 1-ks 0, kuid mitte vastupidi. Näiteks, kui meie mälu rakus oli 0x55, siis pärast 0x0f kirjutamist salvestatakse seal juba 0x05. (vt allolevat tabelit);
3. Kustutamine:
   Muidugi peame suutma teha ka vastupidist operatsiooni — muuta 0-ks 1, just selleks on olemas kustutamise operatsioon. Erinevalt esimestest kahest, toimib see mitte baitidega, vaid plokkidega (valitud mikroskeemi minimaalne kustutusplokk on 4 kB). Kustutamine hävitab kogu ploki ja see on ainus viis 0 muuta 1-ks. Seetõttu tuleb flash-mäluga töötades sageli andmestruktuure joondada kustutusploki piirile.
   NOR Flash'i kirjutamine:

Binaarsed andmed

See oli
01010101

Kirjutasime
00001111

Muutus
00000101

Ise ajakiri esindab muutuva pikkusega kirjeid. Tüüpiline kirje pikkus on umbes 30 baiti (kuigi mõnikord võib esineda ka mitme kilobaidi pikkuseid kirjeid). Selles osas töötame nendega lihtsalt kui baitide kogumiga, kuid kui on huvitav, siis kirjete sees kasutatakse CBOR'i.

Lisaks ajakirjale peame hoidma teatud „seadistamise“ teavet, nii uuendatavat kui ka mitte: mingi seadme ID, andurite kalibreerimine, lipp „seade on ajutiselt väljalülitatud“, jne.
See teave esindab võtme-väärtuse kirjeid, mis samuti salvestatakse CBOR'is. Meil ei ole seda teavet väga palju (kuni paar kilobaiti), see uuendatakse harva.
Edaspidi nimetame seda kontekstiks.

Kui meenutada, millest see artikkel algas, on väga oluline tagada andmete usaldusväärne hoidmine ja, kui võimalik, katkematu töö ka seadme riketel või andmekahjustusel.

Milliseid probleemide allikaid saaks kaaluda?

• Toite katkestamine kirjutamise/kustutamise operatsioonide ajal. See on nagu „miks mitte paljastada vastupidi“.
  Teave aadressilt arutelu stackexchange'ist: toite katkestamise korral flash-mälu töötamise ajal nii kustutamine (1-ks seadmine) kui ka kirjutamine (0-ks seadmine) toovad kaasa määratlemata käitumise: andmed võivad kirjutada, kirjutada osaliselt (ütleme, et edastasime 10 baiti/80 bitti, kuid jõudsime kirjutada ainult 45 bitti), samuti ei saa välistada, et osa bite võib olla „vahepealses“ seisundis (lugemine võib anda nii 0 kui ka 1);
• Flash-mälu enda vead.
  BER on kuigi väga madal, kuid ei tohi olla null;
• Bussi vead
  SPI kaudu edastatavad andmed ei ole mingil viisil kaitstud, võivad tekkida nii üksikud bitivead kui ka sünkroonimisvead — bitide kaotus või lisamine (mis viib massiliste andmete moonutusteni);
• Muud vead/rikkumised
  Koodivead, Raspberry 'glitchid', tulnukate sekkumine…

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

• salvestused peavad minema kohe mälupulgale, edasilükatud salvestust ei arvestata; - kui viga tekib, siis peab see avastatama ja töötlemine toimuma võimalikult varakult; - süsteem peab võimalusel taastama töö pärast vigu.
  (näide elust "kuidas ei peaks olema", millega, arvan, on kõik kokku puutunud: pärast avariilist taaskäivitamist "korrastati" failisüsteem ja operatsioonisüsteem ei käivitu)

Ideed, lähenemised, mõtted

Kui hakkasin sellele ülesandele mõtlema, liikusid mu peas ringi hulgaliselt ideid, näiteks:

• kasutada andmete tihendamist;
• kasutada nutikaid andmestruktuure, näiteks hoida salvestuste päiseid eraldi iseenesest salvestustest, et vigade korral saaksid teised andmed probleemideta lugeda;
• kasutada bitifiltreid salvestuse lõpetamise kontrollimiseks toite väljalülitamisel;
• hoida kontrollsummasid kõigi ja kõige kohta;
• kasutada mingisugust vigadele vastupidavat kodeerimist.

Osad neist ideedest olid kasutusel, mõnel oli otsustanud loobuda. Vaatame järjestikku.

Andmete kokkusurumine

Isiklikud sündmused, mida me logis salvestame, on piisavalt ühesugused ja korduvad ("viskasime 5 rubla mündi", "vajutasime tagasiandmise nuppu", ...). Seetõttu peaks tihendamine olema piisavalt tõhus.

Tihendamise kulud on ebaolulised (meie protsessor on piisavalt võimas, isegi esimesel Pi-l oli üks tuum 700 MHz-l, tänapäevastes mudelites on mitu tuuma, mille sagedus ületab gigahertsi), andmesalvestuse vahetuskiirus ei ole kõrge (mõned megabait sekundis), salvestuste suurus on väike. Üldiselt, kui tihendamine mingil moel jõudlust mõjutab, siis ainult positiivselt. (absoluutselt mitte kriitiline, lihtsalt konstateerin). Plus meil ei ole ju päris embedded, vaid tavaline Linux – seega implementatsioon ei peaks nõudma palju pingutust (piisab lihtsalt raamatukogude lingimisest ja mõne funktsiooni kasutamisest sealt).

Võeti tükk logifailist töötavast seadmest (1,7MB, 70 tuhat kirje) ja alguses kontrolliti selle kokkusurumisvõimet olemasolevate programmide gzip, lz4, lzop, bzip2, xz, zstd abil.

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

Nii et andmed on väga hästi tihendatavad.
Seega (kui me ei leia fataalseid puudusi) tihendamine peaks toimuma! Lihtsalt sellepärast, et sama mälupulgale mahtuda rohkem andmeid.

Mõelgem puudustele.

Esimene probleem: me oleme juba kokku leppinud, et iga kirje peab viivitamatult minema mälupulgale. Tavaliselt kogub arhiveerija andmeid sisendvoogudest kuni otsustab, et on aeg kirjutada väljundisse. Meie peame aga kohe saama tihendatud andmepaketi ja salvestama selle mitte-volatile mällu.

Näen kolme teed:

1. Tihendada iga kirje sõnaraamatutihenduse abil, mitte eelnevalt käsiteldu algoritmide kaudu.
   Töötav variant, kuid see ei meeldi mulle. Teatud kokkusurumise taseme tagamiseks peab sõnaraamat olema „teravdatud“ konkreetsete andmete jaoks, mis tahes muudatus toob kaasa kokkusurumise taseme katastroofilise languse. Jah, probleem lahendatakse uue versiooni sõnaraamatu loomisega, kuid see on peavalu – me peame hoidma kõiki sõnaraamatu versioone; iga kirje puhul peame märkima, millise sõnaraamatu versiooniga see on tihendatud…
2. Tihendada iga kirje „klassikaliste“ algoritmide abil, kuid sõltumatult teistest.
   Käsitletavad kokkusurumise algoritmid ei ole mõeldud selliste suurte kirjetega töötamiseks (kümned baitid), tihenduskoefitsient on ilmselt väiksem kui 1 (st andmete mahu suurenemine, mitte kokkusurumine);
3. Teha FLUSH pärast iga kirjet.
   Paljuski tihendamisraamatukogudes on FLUSH-i tugi. See on käsk (või parameeter tihendamisprotseduurile), mille saades arhiveerija loob tihendatud voog, et sellest lähtudes saaks taastada kõik tihendamata andmed, mis on juba saadud. Selline analoog sync failisüsteemides või commit SQLis.
   Oluline on, et järgnevad tihendamisoperatsioonid saavad kasutada akumuleeritud sõnastikku ning tihendusaste ei kannata nii palju nagu eelnevas variandi puhul.

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

Löydettiin suurepärane artikkel FLUSH-ist zlib-is.

Tehtud inspiratsiooniks artiklist, tegin katse, võttes 70 tuhat päringut päringute logidest reaalsetelt seadmetelt, kui lehe suurus on 60 KB (lehe suuruse juurde me veel naaseme) sain:

Algandmed
gzip tihendamine -9 (ilma FLUSHita)
zlib Z_PARTIAL_FLUSH-iga
zlib Z_SYNC_FLUSH-iga

Maht, KB
1692
40
352
604

Esmapilgul tundub, et FLUSH-i hind on ülemäära kõrge, kuid tegelikult on meie valik vaene — kas mitte üldse tihendada või tihendada (ja väga efektiivselt) FLUSH-iga. Ärge unustage, et meil on 70 tuhat kirjet, Z_PARTIAL_FLUSH-i toodu üleliigusus on ainult 4-5 baiti kirje kohta. Tihenduskoefitsient osutus peaaegu 5:1, mis on suurepärane tulemus.

Võib tunduda üllatav, kuid tegelikult on Z_SYNC_FLUSH efektiivsem viis FLUSH-i tegemiseks.

Kui kasutada Z_SYNC_FLUSH-i, on iga kirje nelja viimast baiti alati 0x00, 0x00, 0xff, 0xff. Kui need on meile teada — siis me ei pea neid salvestama, seega on lõplik suurus vaid 324 KB.

Artiklis, millele viitan, on seletus:

Uus tüüp 0 blokk tühjade sisudega lisatakse.

Tüüp 0 blokk tühjade sisudega koosneb:

• kolmest bitist koosnevast ploki päisest;
• 0 kuni 7 bitti, mis on võrdsed nulliga, et saavutada baitide joondamine;
• neljast baitist koosnevast järjestusest 00 00 FF FF.

Nagu ei ole keeruline märgata, esimeses plokis 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 (alati?) ploki tüüp 1 (fikseeritud plokk), mis kindlasti lõppeb 7 nullbiti, kokku 10-17 garanteeritud nullbitti (ja ülejäänud on nullid umbes 50% tõenäosusega).

Seega 100% juhtudel testandmetel on enne 0x00, 0x00, 0xff, 0xff üks nullbait, ja rohkem kui kolmandal juhul — kaks nullbaidi. (võib-olla on asi selles, et kasutan binaarset CBOR-i, ja tekstilisel JSON-il oleksime võinud sagedamini kohata tüüp 2 plokke — dünaamiline plokk, vastavalt oleksime kohanud plokke ilma lisanduvate nullbaitideta enne 0x00, 0x00, 0xff, 0xff).

Kokkuvõttes on olemasolevate testandmete põhjal võimalik mahtuda alla 250 KB tihendatud andmeid.

Saame veel natukene kokku hoida, tegeledes bittide žongleerimisega: praegu ignoreerime mitme nullbiti olemasolu ploki lõpus, samuti ei muutu mõned bitid ploki alguses...
Aga siis tegin ma tahteotsuse peatuda, muidu võin sellise tempoga jõuda oma arhiiveri loomiseni.

Kokkuvõttes sain oma testandmetelt 3-4 baiti kirjutamiseks, kompressioonikordaja oli üle 6:1. Ausalt öeldes: ma ei oodanud sellist tulemust, minu arvates on kõik, mis on parem kui 2:1 — juba tulemus, mis õigustab kompressiooni kasutamist.

Kõik on suurepärane, kuid zlib (deflate) on ikkagi arkaalne, tuntud ja veidi vanamoeline kompressioonialgoritm. Ainult see, et sõnaraamatuks kasutatakse viimaseid 32Kb tihendamata andmeid, tundub täna kummaline (st kui mõni andmeplokk sarnaneb sellele, mis oli sisendis 40Kb tagasi, siis hakkab see uuesti arhiivima, mitte ei viita varasemale esinemisele). Moodne kaasaegne arhiiver mõõdab sõnaraamatu suurust tihti megabaitides, mitte kilobaitides.

Nii et jätkame meie mini-uuringut arhiivide üle.

J järgmiseks prooviti bzip2 (tuletan meelde, et ilma FLUSHita näitas see fantastilist tihendust, peaaegu 100:1). Kahjuks FLUSHiga ei andnud ta end hästi tunda, tihendatud andmete suurus oli suurem kui tihendamata.

Minu oletused ebaõnnestumise põhjustest

Libbz2 pakub ainult ühte flush-varianti, mis tundub olevat sõnaraamatu puhastamine (analoog Z_FULL_FLUSH zlibis), rääkida mingist tõhusast tihendamisest pärast seda ei saa.

Viimaseks prooviti zstd. Olenevalt parameetritest tihendab ta kas gzipi tasemel, kuid palju kiiremini, või paremini kui gzip.

Kahjuks FLUSHiga ei andnud ka tema end „väga hästi”: tihendatud andmete kogusumma oli umbes 700Kb.

Mina esitasin küsimuse projekti lehe kaudu githubis, sain vastuse, et tuleb arvestada kuni 10 baiti haldusandmeid iga tihendatud andmeploki kohta, mis on lähedal saadud tulemustele, deflate'i mitte mingil juhul ei saavuta.

Sellega otsustasin arhiivide katsetamisel peatuda (tuletan meelde, et xz, lzip, lzo, lz4 ei näidanud ennast veel FLUSHi testimise etapis, ja ma ei hakanud arvestama eksootiliste tihendamisalgoritmidega).

Naaseme arhiivimise probleemide juurde.

Teine probleem (nagu öeldakse järjestuse, mitte tähenduse järgi) on, et kokkusurutud andmed esindavad ühtset voogu, kus pidevalt viidatakse eelnevatele segmentidele. Seega, kui mõni kokkusurutud andmete segment on kahjustatud, kaotame mitte ainult seotud lahtised andmed, vaid ka kõik järgnevad.

Selle probleemi lahendamiseks on mitu lähenemist:

1. Probleemi ennetamine — lisada kokkusurutud andmetesse üleliigsust, mis võimaldab vigu tuvastada ja parandada; sellest räägime hiljem;
2. Minimeerida tagajärjed häire tekkimisel.
   Oleme varem rääkinud, et iga andmeploki saab kokku suruda sõltumatult, mis tähendab, et probleem kaob iseenesest (ühe bloki andmete rikkumine viib ainult selle bloki andmete kaotamiseni). Siiski on see äärmuslik olukord, kus andmete kokkusurumine osutub ebaefektiivseks. Teine äärmus: kasutada kõiki 4MB meie kiipi kui ühte arhiivi, mis annab meile suurepärase kokkusurumise, kuid katastroofilised tagajärjed andmete rikkumise korral.
   Jah, usaldusväärsuse osas on vajalik kompromiss. Kuid tuleb meeles pidada, et me töötame välja andmete salvestamise formaati energiat mitte vajavas mälus, millel on äärmiselt madal BER ja deklareeritud andmete säilitamise aeg 20 aastat.

Eksperimentide käigus avastasin, et märgatavad kokkusurumise taseme kaotused algavad alla 10KB suurustes kokkusurutud andmeplokkides.
Varem mainiti, et kasutatav mälu on leheküljeline, ma ei näe põhjust, miks mitte kasutada vastavust „üks lehekülg — üks kokkusurutud andmeplokk”.

Seega on minimaalne mõistlik lehe suurus 16KB (koos varuga teenindusteabe jaoks). Siiski seab nii väike lehe suurus märkimisväärseid piiranguid maksimaalse andmereservi suurusele.

Kuigi ma ei prognoosi hetkel suuremaid kui ühes kilobaidis kokkusurutud salvestusi, otsustasin kasutada 32KB suuruseid lehti (kokku 128 lehte kiibi kohta).

Kokkuvõte:

• Salvestame andmed kokkusurutud kujul zlib (deflate) abil;
• Iga salvestuse jaoks seadistame Z_SYNC_FLUSH;
• Igal kokkusurutud salvestusel lõikame ära lõppbaidid, (näiteks 0x00, 0x00, 0xff, 0xff); pealkirjas näitame, kui palju baite oleme lõiganud;
• Andmed salvestatakse lehtedena 32 kb kaupa; lehe sees on ühtne kokkupressitud andmevoog; iga lehe jaoks alustame kokkupressimist uuesti.

Ja enne, kui lõpetame kokkupressimise, tahaksin juhtida tähelepanu sellele, et meil õnnestub kokkupressida vaid paar baitit salvestuse kohta, seega on äärmiselt oluline mitte puhtust teavet paisutada, iga bait on siin arvesse võetud.

Andmepealkirjade salvestamine

Kuna meil on muutuva pikkusega salvestused, peame kuidagi määrama salvestuste asukoha/piirid.

Ma tean kolme lähenemist:

1. Kõik salvestused on salvestatud katkematusse voogu, kõigepealt tuleb salvestuse pealkiri, mis sisaldab pikkust, ja seejärel endine salvestus.
   Selles variandis võivad nii pealkirjad kui ka andmed olla muutuva pikkusega.
   Sisuliselt on meil ühekülgne loend, mida kasutatakse pidevalt;
2. Pealkirjad ja salvestused ise on salvestatud eraldi voogudes.
   Kasutades kindla pikkusega pealkirju, saavutame selle, et ühe pealkirja rike ei mõjuta teisi.
   Sarnast lähenemist kasutatakse näiteks paljudes failisüsteemides;
3. Salvestused on salvestatud katkematusse voogu, salvestuse piir määratakse teatud märgiste (sümbolid/sümbolite jada, mis on andmeblokis keelatud) järgi. Kui salvestuses leidub marker, siis asendame selle teatud jadaga (ekreerime selle).
   Sarnast lähenemist kasutatakse näiteks PPP protokollis.

Illustreerin.

Variant 1:

Siin on kõik väga lihtne: teades salvestuse pikkust, saame arvutada järgmise pealkirja aadressi. Nii liigume pealkirjade vahel, kuni leiame 0xFF-ga täidetud ala (vaba ala) või lehe lõpuni.

Variant 2:

Muutuva pikkuse tõttu ei saa me eelnevalt öelda, kui palju salvestusi (seega ka pealkirju) meil lehte läheb. Saame pealkirjad ja andmed jaotada erinevatele lehtedele, kuid mulle meeldib teise lähenemise pooldasem: nii pealkirjad (kindla suurusega) on lehe alguses ja andmed (muutuva pikkusega) lehe lõpust. Kui nad „kohtuvad” (vaba ruumi ei piisa uue salvestuse jaoks) — loeme selle lehe täidetuks.

Variant 3:

Siin pole vajadust hoida päises pikkust või muid andmete asukoha kohta käivaid andmeid, piisab markeritest, mis tähistavad kirjete piire. Siiski tuleb andmeid töödelda kirjutamisel/loodud.
Markerina kasutaksin 0xff (millega leht on täidetud pärast kustutamist), seega ei tõlgendata vabatahtlikku ala tõeks.

Võrdlustabel:

Variant 1
Option 2
Variant 3

Vigade taluvus
—
+
+

Kompaktsus
+
—
+

Rakendamise keerukus
*
**
**

Esimesel variandil on surmav puudus: kui mõni päis on kahjustatud, siis hävib kogu järgmine ahel. Ülejäänud variandid võimaldavad taastada osa andmeid isegi massiliste kahjustuste korral.
Kuid siinkohal on asjakohane meenutada, et otsustasime andmed hoida kokkusurutud kujul, nii et me kaotame kõik andmed lehe peal pärast "rikkuvat" kirje, seega, kuigi tabelis on miinus, ei arvesta me seda.

Kompaktsus:

• esimeses variandis peame päises hoidma ainult pikkust, kui kasutada täisarve muutuva pikkusega, siis enamikul juhtudel piisab ühest baitist;
• teises variandis peame hoidma algset aadressi ja pikkust; kirje peaks olema pideva suurusega, hindan 4 baiti kirje kohta (kaks baiti nihke jaoks ja kaks baiti pikkuse jaoks);
• kolmandale variandile piisab vaid ühest sümbolist kirje alguse tähistamiseks, pluss ise kirje tänu ekraanile suureneb 1-2%. Üldiselt on ligikaudne pariteet esimese variandiga.

Alguses kaalusin teist varianti põhjalikult (ja isegi kirjutasin teostuse). Lõpetasin selle, kui otsustasin lõpuks kasutada kokkusurumist.

Võimalik, et kunagi kasutan sarnast varianti. Näiteks, kui pean tegelema andmete salvestamisega laeva jaoks, mis reisib Maa ja Marsi vahel — täiesti teistsugused nõudmised usaldusväärsusele, kosmiline kiirgus, …

Mis puutub kolmandasse variandisse: panin sellele kaks tähte rakendamise keerukuse tõttu, lihtsalt seetõttu, et ma ei armasta ninaga tegelemist ekraanide, pikkuste muutmiseks jne. Jah, võib-olla olen kallutatud, kuid koodi pean ma ikkagi kirjutama — miks sundida end tegema seda, mis ei meeldi.

Kokkuvõte: valime salvestusvariandi kujul ahelad "päis pikkusega — muutuva pikkusega andmed" efektiivsuse ja rakendamise lihtsuse tõttu.

Bitiväljade kasutamine kirje kirjutamise operatsioonide eduka kontrollimise jaoks

Ma ei mäleta enam, kust ma selle idee sain, aga see näeb enam-vähem välja nii:
Iga kirje jaoks eraldame mitu bitti lipu salvestamiseks.
Kuidas me varem rääkisime, pärast erase’it on kõik bitid täidetud 1-ga ja saame muuta 1 0-ks, aga mitte vastupidi. Seega kasutame "lipp pole seadistatud" jaoks 1 ja "lipp on seadistatud" jaoks 0.

Nii võib välja näha muutuva pikkusega kirje paigutamine flash-mälu:

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

Lisaks on meil "tekkis viga" lipp, kokku 4 bitilist lippu.

Sellisel juhul on meil kaks stabiilset olekut "1111" — salvestamine ei alanud ja "1000" — salvestamine õnnestus; ootamatul salvestamisprotsessi katkestamisel saame vahepealsed olekud, mille saame hiljem tuvastada ja käsitleda.

Lähenemine on huvitav, kuid see kaitseb ainult ootamatute toitekatkestuste ja sarnaste tõrgete eest, mis on muidugi tähtis, kuid see ei ole kaugeltki ainus (ja isegi mitte peamine) võimalik tõrgete põhjus.

Kokkuvõte: Liigume edasi, otsides head lahendust.

Kontrollsummad

Kontrollsummad pakuvad ka võimalust veenduda (piisava tõenäosusega), et loeme just seda, mis pidi olema salvestatud. Ja erinevalt eelnevalt arutatud bitiväljadest töötavad nad alati.

Kui vaadata potentsiaalsete probleemide loetelu, millest me rääkisime, suudab kontrollsumma tuvastada vea sõltumata selle päritolust (v.a. võib-olla pahatahtlikud välismaali inimesed — need võivad ka kontrollsummat valehäirega petta).

Seega, kui meie eesmärk on kontrollida, et andmed on terved, on kontrollsummad suurepärane mõte.

Kontrollsummade arvutamise algoritmi valik ei tekitanud küsimusi — CRC. Ühelt poolt võimaldavad matemaatilised omadused 100% tuvastada teatud tüüpi vigu, teiselt poolt näitab see algoritm juhuslike andmete puhul tavaliselt kokkulangevuste tõenäosust mitte oluliselt suurem kui teoreetiline piir. Olgu see mitte kõige kiirem algoritm, mitte alati minimaalne kokkupõrgete arvu poolest, kuid tal on üks väga oluline omadus: testides, millega olen kokku puutunud, ei ole olnud mustreid, kus see selgelt ebaõnnestuks. Stabiilsus on antud juhul peamine kvaliteet.

Rohke uurimistöö näide: osa 1, Osa 2 (linkidena narod.ru, vabandust).

Siiski ei ole kontrollsummade valimise ülesanne veel lõppenud, CRC on terve kontrollsummade perekond. Tuleb otsustada pikkuse üle ja seejärel valida polünoom.

Kontrollsummade pikkuse valik ei ole nii lihtne küsimus, kui esmapilgul tundub.

Illustreerime:
Olgu meil veavoodus iga bait ja ideaalne kontrollsumma, arvutame keskmise veahulga miljoni kirje kohta:

Andmed, bait
Kontrollsumma, bait
Tuvastamata vead
Vale tuvastamine
Kokku vale signaalide arv

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

Paistab, et kõik on lihtne — vali kaitstud andmete pikkuse põhjal kontrollsumma pikkus miinimumiga vale signaalide arvuga — ja asi on korras.

Siiski, lühikeste kontrollsummadega on probleem: kuigi need tuvastavad hästi üksikuid bitti vigu, võivad nad piisavalt suure tõenäosusega lugeda täiesti juhuslikke andmeid õigeks. Habrés on juba olnud artikkel, mis kirjeldab probleemi reaalses elus.

Seetõttu, et muuta kontrollsummade juhusliku kokkulangemise praktiline võimalus peaaegu võimatuks, tuleb kasutada vähemalt 32-bitiseid kontrollsummasid (üle 64 bitise pikkuse puhul kasutatakse tavaliselt krüptograafilisi räsifunktsioone).

Kuigi ma olen varem kirjutanud, et tuleb iga hinna eest ruumi kokku hoida, kasutame siiski 32-bitist kontrollsummat (16 bitti on liiga vähe, kokkupõrgete tõenäosus on üle 0,01%; 24 bitti on, nagu öeldakse, ei siia ega sinna).

Siin võib tekkida vastuväide: kas me tõesti säästsime iga baidi kompressimise valimisel, et nüüd anda kohe 4 baiti? Ei ole ju parem mitte tihendada ja mitte kontrollsummat lisada? Loomulikult ei, tihendamise puudumine ei tähenda, et me ei vaja terviklikkuse kontrolli.

Polünoomi valimise osas ei hakka me ratast leiutama, vaid võtame populaarsed CRC-32C.
See kode tuvastab 6 bittviga pakettides, mille suurus on kuni 22 baiti (ilmselt kõige levinum juhtum meie jaoks), 4 bittviga pakettides, mille suurus on kuni 655 baiti (ka levinud juhtum meie jaoks), 2 või mis tahes paaritu arv bittvigu pakettides, mille suurus on mõistlik.

Kui kedagi huvitavad üksikasjad

Wikipedia artikkel CRC kohta.

CRC-32C koodi parameetrid . Tundub, et Kaupmani veebis — ilmselt peamine ekspert CRC alal maailmas.

Uues tema artiklis on veel üks huvitav kood, mis tagab veidi paremad parameetrid meie jaoks asjakohaste pakettide pikkuste jaoks, kuid ma ei pidanud vahet oluliseks ja olen piisavalt kompetentne, et valida kohandatud kood standardse ja põhjalikult uuritud koodi asemel.

Veelgi enam, kuna meil on andmed kokku surutud, on küsimus: kas arvestada kontrollsummat surutud või mitte surutud andmetest?

Argumente surutud andmete kontrollsummana:

• meil on lõpuks vaja kontrollida andmete säilitamise ohutust — nii et me kontrollime seda otse (samuti kontrollitakse võimalikud vigadega seotud puudujäägid kompressiooni/dekompressiooni rakendamises, mälurikked jms);
• algoritm deflate zlibis on piisavalt küps ja ei tohiks kukutada «kruvitud» sisendandmete korral, pealegi on ta sageli võimeline iseseisvalt tuvastama vigu sisendvoos, vähendades seeläbi üldist tõenäosust, et viga jääb tuvastamata (tegin testi, kus inversioon lühelt bitilt, zlib tuvastas vea ligikaudu kolmandal juhul).

Argumente surutud andmete kontrollsummana:

• CRC on just loodud väheste bittvigade jaoks, mis iseloomustavad flash-mälu (bittviga surutud voos võib põhjustada massilist muudatust väljundvoos, kus me teoreetiliselt võime «püüda» kolisiooni);
• mulle ei meeldi idee edastada dekompressorile potentsiaalselt vigaseid andmeid, kes teab, kuidas ta reageerib.

Selles projektis otsustasin kõrvale kalduda tavapärasest praktikast, kus säilitada kontrollsummat mitte surutud andmetest.

Kokkuvõte: kasutame CRC-32C, kontrollsummat arvutame andmetelt sellisel kujul, nagu need salvestatakse flash-mällu (pärast surumist).

Üksus

Liigne üleliigse kodeerimise kasutamine ei võimalda andmete kaotust täielikult välistada, kuid see võib oluliselt (tihti kordades) vähendada taastamatute andmete kaotuse tõenäosust.

Saame kasutada erinevaid ülearuse, et vigu korrigeerida.
Hamming'i koodid suudavad parandada üksikute bittide vigu, Reed-Salomon koodid on sümboolsed, mitmed andmekopeerimised koos kontrollsummadega või duplikaatkodeerimine nagu RAID-6 võivad aidata andmeid taastada isegi massiliste riketega.
Alguses olin ma seadnud eesmärgiks laialdase vigadevastase kodeerimise kasutamise, kuid hiljem mõistsin, et esmalt tuleb teada, millistest vigadest me soovime end kaitsta, ja alles seejärel valida kodeerimine.

Rääkisime varem, et vigu tuleb tuvastada võimalikult kiiresti. Millistes olukordades me võime vigadega kokku puutuda?

1. Katkestatud salvestamine (mingil põhjusel, näiteks toitekatkestuse, Raspberry riistvara hangumise tõttu jne)
   Kahjuks jääb sellise vea korral ainus võimalus, et ignoreerida kehtetuks osutunud salvestusi ja pidada andmeid kadunuks;
2. Salvestamise vead (mingil põhjusel kirjutati flash-mä памяти midagi muud, kui oli plaanitud)
   Selliseid vigu saame koheselt tuvastada, kui teeme pärast salvestamist kontrollimist.
3. Andmete moonutamine mälus salvestamise käigus;
4. Lugemisvead
   Vea parandamiseks piisab, kui kontrollsumma mittesobivuse korral lugemist mitu korda korrata.

Seega ei saa ainult kolmanda tüübi vead (andmete iseeneslik riknemine salvestamise ajal) parandada ilma vigadevastase kodeerimiseta. Tall on usutav, et sellised vead on siiski äärmiselt ebatõenäolsed.

Kokkuvõte: otsustasime loobuda üleliigsest kodeerimisest, kuid kui kasutamine näitab, et see otsus on vale, siis naaseme küsimuse juurde (koos akumuleeritud statistika riketest, mis võimaldab valida optimaalse kodeerimistüübi).

Muud

Loomulikult ei võimalda artikli formaat iga detaili selgitada (ja minu energia on juba ammendunud), seega lähen lühidalt üle mõningate punktide, mida varem ei puudutatud.

• Otsustati, et kõik lehed on "võrdväärsed"
  See, there won't be any special pages with metadata, separate streams, etc., instead, there will be a single stream that rewrites all pages sequentially.
  This ensures even wear of the pages, eliminates a single point of failure, and it's simply preferable;
• It is essential to provide for versioning of the format.
  A format without a version number in the header is evil!
  It's enough to add a field with some Magic Number (signature) in the page header that indicates the version of the format being used. (I don't think there will be even a dozen of them in practice);
• Use a variable-length header for records (of which there are many), aiming to make it 1 byte in length for most cases;
• To encode the length of the header and the length of the trimmed part of the compressed record, use variable-length binary codes.

Was very helpful the online generator of Huffman codes. It took just a few minutes to find the necessary variable-length codes.

Data storage format description

Byte order

Fields larger than one byte are stored in big-endian format (network byte order), meaning that 0x1234 is written as 0x12, 0x34.

Paging

All flash memory is divided into equal-sized pages.

The default page size is 32KB, but no more than 1/4 of the total size of the memory chip (for a 4MB chip, there are 128 pages).

Each page stores data independently of the others (meaning the data of one page does not reference the data of another page).

All pages are numbered in natural order (in ascending address order), starting from number 0 (the zero page starts at address 0, the first at 32KB, the second at 64KB, etc.).

The memory chip is used as a circular buffer (ring buffer), meaning that the writing first goes to page number 0, then to number 1, …, when we fill the last page, a new cycle begins and writing continues from the zero page.

Inside the page

At the beginning of the page is a 4-byte page header, followed by a header checksum (CRC-32C), and then records are stored in the format 'header, data, checksum'.

The page header (shown in dark green in the diagram) consists of:

• a two-byte Magic Number field (which is also the version format indicator)
  for the current version of the format, it is considered as 0xed00 ⊕ lehe number;
• kahebaidise loendur «Lehe versioon» (mäluringi kirjutamise number).

Lehe salvestused salvestatakse kokku surutud kujul (kasutatakse deflate algoritmi). Kõik salvestused ühel lehel surutakse ühes voos (kasutatakse ühise sõnaraamatuga), igal uuel lehel hakkab surumine uuesti. Seega vajab iga salvestuse dekompressioon kõiki eelnevaid salvestusi sellelt lehelt (ja ainult sellest).

Iga salvestus surutakse Z_SYNC_FLUSH märgiga, samas on kokku surutud voolu lõpus 4 baiti 0x00, 0x00, 0xff, 0xff, ees võib olla üks või kaks nullbaiti.
Seda järjestust (pikkusega 4, 5 või 6 baiti) me ei salvesta välkpöördes.

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

• ühe bitti (T), mis tähistab salvestuse tüüpi: 0 — kontekst, 1 — päevik;
• muutuva pikkusega välja (S) 1 kuni 7 bitti, mis määrab pealkirja pikkuse ja „sabaga“, mis tuleb lisada salvestusele dekompressiooniks;
• salvestuse pikkuse (L).

Väärtuste tabel S:

S
Pealkirja pikkus, bait
Salvestamisel eemaldatav, bait

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)

Proovisin illustreerida, ei tea, kui selgelt see õnnestus:

Kollane esindab siin välja T, valge — välja S, roheline L (surutud andmete pikkus baitides), sinine — surutud andmed, punane — surutud andmete lõppbaitid, mida ei kirjutata välkpöördesse.

Seega saame kõige levinuma pikkusega salvestuste pealkirjad (kuni 63+5 baiti surutud kujul) salvestada ühe baitiga.

Iga salvestuse järel on kontrollsummana CRC-32C, mille algväärtused (init) võetakse eelneva kontrollsummat väärtusest.

CRC-l on „jätkusuutlikkuse“ omadus, see toimib (pluss-minus bittide pööramine protsessis) sellise valemiga: .
Seega arvutame tegelikult CRC kõigist eelnevatest baitidest pealkirjades ja andmetes sellel lehel.

Otseselt kontrollsummale järgneb järgmise salvestuse pealkiri.

Pealkiri on konstrueeritud nii, et selle esimene bait oleks alati erinev 0x00 ja 0xff (kui pealkirja esimesele baitile satume 0xff, siis tähendab see, et see on kasutamata ala; 0x00 aga signaalib tõrget).

Umbes algoritmid

Lugemine välkpöördest

Iga lugemine toimub kontrollsummade kontrollimisega.
Kui kontrollsumma ei kattu, loetakse andmeid mitu korda lootes õiged andmed siiski lugeda.

(see on mõttekas, Linux ei vaheta NOR Flash'i lugemist, on kontrollitud)

Salvestamine mälukiipidesse

Salvestame andmed.
Lugeme need.

Kui loetud andmed ei lange kokku salvestatud andmetega, täidame ala nullidega ja anname teada veast.

Uue kiibi tööks ettevalmistamine

Initsialiseerimiseks salvestatakse esimesse (täpsemalt nullsesse) lehte versiooniga 1 pealkiri.
Pärast seda salvestatakse sellele lehele algne kontekst (sisaldab automaadi UUID ja vaikeseaded).

Kõik, mälukiip on töötamiseks valmis.

Automaatide laadimine

Laadimise käigus loetakse iga lehe esimesed 8 baiti (pealkiri + CRC), lehti, millel on tundmatu Magic Number või vale CRC, ignoreeritakse.
Õigeid lehti valitakse maksimaalse versiooniga lehtede seast, neist võetakse leht, millel on kõrgeim number.
Loetakse esimene kirje, kontrollitakse CRC õigsust, konteksti lipu olemasolu. Kui kõik on korras, loetakse see leht jooksvaks. Kui ei, siis tagastame eelnevale lehele, kuni leiame 'elava' lehe.
Ja leitud lehelt loeme kõik kirjed, neid, millel on konteksti lipp, rakendame.
Salvestame zlib sõnastiku (see on vajalik selle lehe täiendamiseks).

Kõik, laadimine on lõpule viidud, kontekst on taastatud, saab töötada.

Kande lisamine päevikusse

Kandme surumise õige sõnastiku abil, kasutades Z_SYNC_FLUSH. Kontrollime, kas surutud kande mahub praegusele lehele.
Kui ei mahuta (või lehel oli CRC vigu) - alustame uut lehte (vt alla).
Salvestame kande ja CRC. Kui esines viga - alustame uut lehte.

Uus leht

Valime vaba lehe, millel on madalaim number (vabana peame lehte, millel on vale kontrollsumma pealkirjas või mille versioon on väiksem kui praegune). Kui selliseid lehti ei ole, valime lehe, millel on minimaalne number ja mille versioon on võrdne praegusega.
Teeme valitud lehe erase. Kontrollime sisu 0xff vastu. Kui midagi on valesti - võtame järgmise vaba lehe jne.
Kustutatud lehele salvestame pealkirja, esimese kirjana praeguse konteksti oleku, järgmise - kirjutamata päevikukande (kui see on olemas).

Formaadi kohaldatavus

Minu arvates on see hea formaat mis tahes mõõdukaid andmeid (lihtne tekst, JSON, MessagePack, CBOR, võib-olla protobuf) salvestamiseks NOR Flashis.

Muidugi, formaat on 'kohandatud' SLC NOR Flash jaoks.

Seda ei tohiks kasutada seadmetega, millel on kõrge BER, nagu NAND või MLC NOR. (Kas sellist mälu on üldse müügis? Olen kohanud viiteid ainult vigade parandamise teadusartiklites.).

Veelgi enam, seda ei tohiks kasutada seadmetega, millel on oma FTL: USB flash, SD, MicroSD jne. (Sellele mälule olen ma teinud formaadi, mille lehekülje suurus on 512 baiti, allkirjaga iga lehe alguses ja unikaalsete kirje numbritega — mõnikord õnnestus 'glitch' flashilt lihtsa järjestikuse lugemisega kõik andmed taastada.).

Sõltuvalt ülesannetest saab formaati kasutada ilma muutmisteta mälupulkadel vahemikus 128Kbit (16Kb) kuni 1Gbit (128Mb). Soovi korral saab seda kasutada ka suurema mahutavusega kiipidel, kuid tõenäoliselt tuleb lehekülje suurust kohandada. (Aga siin kerkib juba esile majanduslik otstarbekus, NOR Flashi suur mahutus ei ole odav.).

Kui kellelegi tundus formaat huvitav ja ta tahab seda kasutada avatud projektis — kirjutage, püüan leida aega koodi korrigeerimiseks ja üles laadimiseks Githubi.

Kokkuvõte

Kuidas näha, osutus formaat lõpuks lihtsaks. ja lausa igavaks..

Artikli formaadis on raske kajastada oma seisukoha arengut, kuid uskuge mind: alguses tahtsin luua midagi keerukat ja purunematut, mis suudaks ellu jääda isegi tuumapommi läheduses. Kuid mõistus (loodetavasti) siiski võitis ja prioriteedid nihkusid järk-järgult lihtsuse ja kompaktsetuse suunas.

Kas on võimalik, et ma eksisin? Jah, loomulikult. Täiesti võimalik on näiteks, et oleme ostnud partiid halva kvaliteediga kiipe. Või mõnel muul põhjusel ei vasta seade ootustele usaldusväärsuse osas.

Kas mul on selle juhtumi jaoks plaan? Ma arvan, et artikkel lugedes ei kahtle te, et plaan on. Ja isegi mitte üks.

Kui rääkida veidi tõsisemalt, siis formaat on välja töötatud samaaegselt nii tööversioonina kui ka 'katseõhku laskmiseks'.

Hetkel töötab kõik laua peal normaalselt, mõni päev tagasi võetakse lahendus kasutusele. (umbes) saja saja seadme, vaatame, mis juhtub "lahing" kasutuses (loodetavasti võimaldab formaat usaldusväärselt vigu tuvastada; nii et saab koguda täielikku statistikat). Paari kuu pärast saab järeldusi teha. (ja kui õnne pole, siis ka varem).

Kui kasutamise tulemused paljastavad tõsiseid probleeme ja täiendavaid arendusi on vaja, siis kirjutan sellest kindlasti.

Kirjandus

Ei tahtnud koostada pikka igavat nimekirja kasutatud töödest, lõpuks on Google kõigile olemas.

Siin otsustasin jätta loetelu leidudest, mis tundusid mulle eriti huvitavad, kuid järk-järgult said need otse artikli tekstis, ja nimekirjas jäi alles ainult üks punkt:

1. Utiliit infgen autor zlib. Suudab selgelt kuvada deflate/zlib/gzip arhiivide sisu. Kui pead arvestama deflate (või gzip) formaadi sisemise struktuuriga — soovitan soojalt.

Allikas: habr.com