Contexte

Il existe des distributeurs automatiques de notre propre conception. À l'intérieur du Raspberry Pi et un peu de cerclage sur une carte séparée. Un accepteur de pièces, un accepteur de billets, un terminal bancaire sont connectés ... Un programme auto-écrit gère tout. L'historique complet de l'œuvre est écrit dans le magazine sur une clé USB (MicroSD), qui est ensuite transmis via Internet (à l'aide d'un modem USB) au serveur, où il est ajouté à la base de données. Les informations de vente sont chargées en 1s, il y a aussi une interface web simple pour le suivi, etc.

C'est-à-dire que le magazine est vital - pour la comptabilité (les revenus, les ventes, etc.), le suivi (toutes sortes de défaillances et autres circonstances de force majeure); ceci, vous pouvez dire, toutes les informations que nous avons sur cette machine.

Le problème

Les lecteurs flash se présentent comme des appareils très peu fiables. Ils échouent avec une régularité enviable. Cela entraîne à la fois un arrêt de la machine et (si pour une raison quelconque le journal n'a pas pu être transmis en ligne) une perte de données.

Ce n'est pas la première expérience d'utilisation de lecteurs flash, avant qu'il y ait un autre projet avec plus d'une centaine d'appareils où le magazine était stocké sur des lecteurs flash USB, il y avait aussi des problèmes de fiabilité, parfois le nombre de pannes par mois était de l'ordre de la dizaine. Nous avons essayé différents lecteurs flash, y compris ceux de marque sur la mémoire SLC, et certains modèles sont plus fiables que d'autres, mais le remplacement des lecteurs flash n'a pas résolu radicalement le problème.

Attention! Longrid! Si vous n'êtes pas intéressé par le «pourquoi», mais uniquement par le «comment», vous pouvez immédiatement aller à la fin de l' article.

Solution

La première chose qui vient à l'esprit: abandonner MicroSD, mettre, par exemple, SSD et démarrer à partir de celui-ci. C'est théoriquement possible, probablement, mais relativement cher et pas si fiable (un adaptateur USB-SATA est ajouté; sur les SSD à petit budget, les statistiques de défaillance ne sont pas satisfaisantes non plus).

Le disque dur USB ne semble pas non plus une solution particulièrement attrayante.

Par conséquent, nous sommes arrivés à cette option: laisser le téléchargement depuis MicroSD, mais les utiliser en mode lecture seule, et stocker le journal des opérations (et d'autres informations uniques à un matériel spécifique - numéro de série, étalonnages des capteurs, etc.) ailleurs.

Le sujet de la FS en lecture seule pour les framboises a déjà été étudié à plusieurs reprises, je ne m'attarderai pas sur les détails de la mise en œuvre dans cet article (mais s'il y a un intérêt, j'écrirai peut-être un mini-article sur ce sujet) . Le seul point que je veux noter: à la fois par expérience personnelle et par des critiques qui ont déjà mis en place un gain de fiabilité, c'est. Oui, il est impossible de se débarrasser complètement des pannes, mais il est tout à fait possible de réduire considérablement leur fréquence. Oui, et les cartes deviennent unifiées, ce qui simplifie considérablement le remplacement du personnel de maintenance.

Matériel informatique

Il n'y avait aucun doute sur le choix du type de mémoire - NOR Flash.
Arguments:

• connexion simple (le plus souvent le bus SPI, l'expérience d'utilisation qui est déjà là, donc pas de problèmes "de fer" à prévoir);
• prix ridicule;
• protocole d'exploitation standard (l'implémentation est déjà dans le noyau Linux, si vous le souhaitez, vous pouvez prendre un tiers, qui est également présent, ou même écrire le vôtre, l'avantage est simple);
• fiabilité et ressource:
  à partir d'une fiche technique typique: les données sont stockées pendant 20 ans, 100 000 cycles d'effacement pour chaque bloc;
  à partir de sources tierces: BER extrêmement bas, il est postulé qu'il n'y a pas besoin de codes de correction d'erreur (dans certains articles, ECC pour NOR est pris en compte, mais généralement MLC NOR est là, cela arrive) .

Estimons les besoins en volume et en ressources.

Je veux avoir la garantie de sauvegarder les données pendant plusieurs jours. Cela est nécessaire pour qu'en cas de problème de connexion, l'historique des ventes ne soit pas perdu. Nous allons nous concentrer sur 5 jours, pendant cette période (même en tenant compte des week-ends et jours fériés), nous pouvons résoudre le problème.

Nous tapons maintenant environ 100 Ko de magazine par jour (3 à 4 000 enregistrements), mais progressivement ce chiffre augmente - les détails augmentent, de nouveaux événements sont ajoutés. De plus, il y a parfois des salves (certains capteurs commencent à envoyer du spam avec des faux positifs, par exemple). Nous calculerons 10 mille enregistrements de 100 octets - mégaoctets par jour.

Un total de 5 Mo de données propres (bien compressibles) sort. Ils ont également (estimation approximative) 1 Mo de données de service.

Autrement dit, nous avons besoin d'une puce de 8 Mo si vous n'utilisez pas la compression, ou de 4 Mo si vous l'utilisez. Des nombres bien réels pour ce type de mémoire.

En ce qui concerne la ressource: si nous prévoyons que la mémoire entière ne sera réécrite pas plus d'une fois tous les 5 jours, alors en 10 ans de service, nous obtenons moins de mille cycles de réécriture.
Je me souviens, le constructeur promet cent mille.

Si les détails sont intéressants, c'est la puce at25df321a qui a été choisie (cependant, c'est insignifiant, il y a beaucoup d'analogues sur le marché qui sont compatibles avec le brochage et le système de commande; même si nous voulons mettre la puce d'un autre fabricant et / ou d'un autre volume, tout fonctionnera sans changer le code) .

J'utilise le pilote intégré au noyau Linux, sur Raspberry, grâce à la prise en charge de la superposition de l'arborescence des périphériques, tout est très simple - vous devez mettre la superposition compilée dans / boot / overlays et modifier un peu /boot/config.txt.

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

 dtoverlay=at25:spimaxfrequency=50000000 

Je vais omettre la description de la connexion de la puce au Raspberry Pi. D'une part, je ne suis pas un expert en électronique, d'autre part, tout est trivial même pour moi: le microcircuit n'a que 8 jambes, dont nous avons besoin de masse, d'alimentation, SPI (CS, SI, SO, SCK); les niveaux coïncident avec ceux du Raspberry Pi, aucune liaison supplémentaire n'est requise - il suffit de connecter les 6 contacts spécifiés.

Énoncé du problème

Comme d'habitude, la formulation du problème passe par plusieurs itérations, il me semble que le moment est venu pour la suivante. Arrêtons-nous donc, rassemblons ce qui a déjà été écrit et clarifions les détails qui restent dans l'ombre.

Nous avons donc décidé que le journal serait stocké dans SPI NOR Flash.

Le journal lui-même représente une séquence d'enregistrements de longueur variable. Une longueur d'enregistrement typique est d'environ 30 octets (bien que des enregistrements de plusieurs kilo-octets se produisent parfois). Dans ce cas, nous travaillons avec eux comme un ensemble d'octets, mais, si vous êtes intéressé, CBOR est utilisé dans les enregistrements.

En plus du journal, nous devons stocker certaines informations de "réglage", qu'elles soient mises à jour ou non: un certain ID d'appareil, l'étalonnage du capteur, l'indicateur "l'appareil est temporairement désactivé", etc.
Ces informations sont un ensemble d'enregistrements de valeurs-clés, également stockés dans CBOR. Nous n'avons pas beaucoup de ces informations (quelques kilo-octets maximum), elles sont rarement mises à jour.
À l'avenir, nous l'appellerons contexte.

Si vous vous souvenez où cet article a commencé, il est très important de garantir la fiabilité du stockage des données et, si possible, un fonctionnement continu même en cas de panne matérielle / corruption de données.

Quelles sources de problèmes peuvent être envisagées?

• Mettez hors tension pendant les opérations d'écriture / effacement. Il s'agit de la catégorie «contre la ferraille sans réception».
  Informations issues de la discussion sur stackexchange: lorsque l'alimentation est coupée lorsque vous travaillez avec le flash, cet effacement (mise à 1), cette écriture (mise à 0) conduisent à un comportement indéfini: les données peuvent être écrites, partiellement écrites (disons, nous avons transféré 10 octets / 80 bits , et seulement 45 bits ont réussi à être enregistrés), il est également possible que certains des bits soient à l'état "intermédiaire" (la lecture peut produire soit 0 soit 1);
• Erreurs de la mémoire flash elle-même.
  Le BER, bien que très faible, ne peut pas être égal à zéro;
• Erreurs de bus
  Les données transmises via SPI ne sont en aucun cas protégées, cela peut très bien se produire sous la forme d'erreurs sur un seul bit ou d'erreurs de synchronisation - perte ou insertion de bits (ce qui entraîne une distorsion massive des données);
• Autres erreurs / échecs
  Erreurs dans le code, "pépins" de framboise, intervention extraterrestre ...

J'ai formulé des exigences, dont la satisfaction, à mon avis, est nécessaire pour assurer la fiabilité:

• Les enregistrements doivent être écrits dans la mémoire flash immédiatement, l'enregistrement en attente n'est pas pris en compte; - si une erreur se produit, elle doit être détectée et traitée dès que possible; - le système doit, si possible, se remettre des erreurs.
  (un exemple tiré de la vie "comme il ne devrait pas être", que tout le monde a rencontré, je pense: après un redémarrage d'urgence, le système de fichiers "s'est cassé" et le système d'exploitation ne démarre pas)

Idées, approches, réflexions

Quand j'ai commencé à penser à cette tâche, un tas d'idées m'a traversé la tête, par exemple:

• Utiliser la compression des données
• Utilisez des structures de données délicates, par exemple, stockez les en-têtes d'enregistrement séparément des enregistrements eux-mêmes, de sorte que si une erreur se produit dans un enregistrement, vous pouvez lire le reste sans problème
• utiliser des champs de bits pour contrôler l'intégralité de l'enregistrement lorsque l'alimentation est coupée;
• stocker des sommes de contrôle pour tout et tout;
• utiliser une sorte de codage correcteur d'erreurs.

Certaines de ces idées ont été utilisées, d'autres ont été décidées à refuser. Allons dans l'ordre.

Compression des données

Les événements que nous enregistrons dans le journal eux-mêmes sont tout à fait les mêmes et répétables ("jeté une pièce de 5 roubles", "cliqué sur le bouton de livraison de changement", ...). Par conséquent, la compression devrait être assez efficace.

La surcharge pour la compression est insignifiante (le processeur que nous avons est assez puissant, même sur le premier Pi il y avait un cœur avec une fréquence de 700 MHz, sur les modèles actuels il y avait plusieurs cœurs avec une fréquence de plus d'un gigahertz), la vitesse d'échange avec le stockage est faible (plusieurs mégaoctets par seconde), la taille d'enregistrement est petite. En général, si la compression affectera les performances, alors seulement positive (absolument non critique, simplement déclarée) . De plus, nous n'avons pas de véritable Linux embarqué, mais ordinaire - donc l'implémentation ne devrait pas nécessiter beaucoup d'efforts (il suffit de lier la bibliothèque et d'utiliser plusieurs fonctions).

Une partie du journal a été extraite du périphérique de travail (1,7 Mo, 70000 enregistrements) et pour commencer, sa compressibilité a été vérifiée à l'aide des gzip, lz4, lzop, bzip2, xz, zstd disponibles sur l'ordinateur.

• gzip, xz, zstd ont montré des résultats similaires (40 Ko).
  J'ai été surpris que le xz à la mode se soit montré ici au niveau gzip ou zstd;
• lzip avec les paramètres par défaut a donné un résultat légèrement pire;
• lz4 et lzop n'ont pas donné de très bons résultats (150 Ko);
• bzip2 a montré des résultats étonnamment bons (18 Ko).

Les données sont donc très bien compressées.
Donc (si nous ne trouvons pas de défauts fatals) il devrait y avoir une compression! Tout simplement parce que plus de données tiendront sur le même lecteur flash.

Réfléchissons aux défauts.

Premier problème: nous avons déjà convenu que chaque disque devrait immédiatement se mettre à clignoter. Habituellement, l'archiveur collecte les données du flux d'entrée jusqu'à ce qu'il décide qu'il est temps d'écrire sur la sortie. Nous devons immédiatement obtenir un bloc de données compressé et l'enregistrer dans une mémoire non volatile.

Je vois trois façons:

1. Compressez chaque entrée en utilisant la compression du dictionnaire au lieu des algorithmes décrits ci-dessus.
   C'est une option qui fonctionne, mais je ne l'aime pas. Pour garantir un niveau de compression plus ou moins décent, le dictionnaire doit être «affiné» pour des données spécifiques, tout changement entraînera une baisse catastrophique du niveau de compression. Oui, le problème est résolu en créant une nouvelle version du dictionnaire, mais c'est un casse-tête - nous devrons stocker toutes les versions du dictionnaire; dans chaque entrée, nous devrons indiquer avec quelle version du dictionnaire il a été compressé ...
2. Compressez chaque entrée avec des algorithmes "classiques", mais indépendamment des autres.
   Les algorithmes de compression considérés ne sont pas conçus pour fonctionner avec des enregistrements de cette taille (dizaines d'octets), le coefficient de compression sera clairement inférieur à 1 (c'est-à-dire une augmentation de la quantité de données au lieu de la compression);
3. Faites FLUSH après chaque enregistrement.
   De nombreuses bibliothèques de compression prennent en charge FLUSH. Il s'agit d'une commande (ou paramètre de la procédure de compression), à la réception de laquelle l'archiveur génère un flux compressé afin que toutes les données non compressées qui ont déjà été reçues puissent être restaurées. Un tel analogue de sync dans les systèmes de fichiers ou de commit dans SQL.
   Ce qui est important, les opérations de compression suivantes pourront utiliser le dictionnaire accumulé et le taux de compression ne souffrira pas autant que dans la version précédente.

Je pense qu'il est évident que j'ai choisi la troisième option, approfondissons-la.

Il y avait un excellent article sur FLUSH dans zlib.

J'ai fait un test motivé basé sur l'article, pris 70 000 entrées de journal à partir d'un appareil réel, avec une taille de page de 60 Ko (nous reviendrons à la taille de la page) :

À première vue, le prix introduit par FLUSH est excessivement élevé, mais en réalité nous avons un mauvais choix - soit ne pas compresser du tout, soit compresser (et très efficacement) avec FLUSH. N'oubliez pas que nous avons 70 000 enregistrements, la redondance introduite par Z_PARTIAL_FLUSH n'est que de 4 à 5 octets par enregistrement. Et le taux de compression s'est avéré être presque 5: 1, ce qui est plus qu'un excellent résultat.

Au total, j'ai obtenu 3-4 octets par enregistrement de mes données de test, le taux de compression était supérieur à 6: 1. Honnêtement, je ne comptais pas sur un tel résultat, à mon avis tout ce qui est meilleur que 2: 1 est déjà un résultat qui justifie l'utilisation de la compression.

Tout va bien, mais zlib (dégonfler) est toujours archaïque algorithme de compression bien mérité et légèrement démodé. Le simple fait que les 32 derniers Ko du flux de données non compressés soient utilisés comme dictionnaire semble étrange aujourd'hui (c'est-à-dire que si un bloc de données est très similaire à ce qui était dans le flux d'entrée de 40 Ko en arrière, il recommencera à être archivé, mais ne sera pas voir l'entrée précédente). Dans à la mode Le dictionnaire de taille des archiveurs modernes est souvent mesuré en mégaoctets plutôt qu'en kilo-octets.

Nous continuons donc notre mini-étude des archiveurs.

Le prochain bzip2 a été testé (rappel, sans FLUSH, il a montré un taux de compression fantastique, presque 100: 1). Hélas, avec FLUSH cela se montrait très mal, la taille des données compressées était supérieure à celle des données non compressées.

Et zstd a été le dernier à être testé. Selon les paramètres, il se comprime soit au niveau gzip, mais beaucoup plus rapidement, ou gzip est meilleur.

Hélas, avec FLUSH, il s'est avéré «pas très»: la taille des données compressées était d'environ 700 Ko.

J'ai posé une question sur la page du projet dans github, j'ai obtenu une réponse selon laquelle il vaut la peine de compter jusqu'à 10 octets de données de service pour chaque bloc de données compressées, ce qui est proche des résultats, la capture du dégonflage ne fonctionne pas.

J'ai décidé de m'arrêter là-dessus dans des expériences avec des archiveurs (je vous rappelle que xz, lzip, lzo, lz4 ne se sont pas montrés même au stade des tests sans FLUSH, mais je n'ai pas considéré d'algorithmes de compression plus exotiques).

Nous revenons aux problèmes d'archivage.

Le deuxième problème (comme on dit dans l'ordre, mais pas en valeur) - les données compressées sont un flux unique dans lequel il est constamment envoyé vers les sections précédentes. Ainsi, lorsqu'une section de données compressées est endommagée, nous perdons non seulement le bloc de données non compressées qui lui est associé, mais aussi toutes les suivantes.

Il existe une approche pour résoudre ce problème:

1. Empêchez l'apparition d'un problème - ajoutez une redondance aux données compressées, ce qui permettra d'identifier et de corriger les erreurs; nous en parlerons plus tard;
2. Minimisez les conséquences en cas de problème
   Nous avons déjà dit précédemment qu'il est possible de compresser chaque bloc de données indépendamment, et le problème disparaîtra de lui-même (la corruption des données d'un bloc entraînera la perte de données de ce bloc uniquement). Cependant, il s'agit d'un cas extrême dans lequel la compression des données sera inefficace. L'extrême opposé: utilisez les 4 Mo de notre microcircuit comme une seule archive, ce qui nous donnera une excellente compression, mais des conséquences catastrophiques en cas de corruption de données.
   Oui, un compromis est nécessaire en termes de fiabilité. Mais nous devons nous rappeler que nous développons un format de stockage de données pour la mémoire non volatile avec un BER extrêmement bas et une période de stockage de données déclarée de 20 ans.

Au cours des expériences, j'ai constaté que des pertes plus ou moins notables dans le niveau de compression commencent sur des blocs de données compressés d'une taille inférieure à 10 Ko.
Il a été mentionné plus tôt que la mémoire utilisée a une organisation de page, je ne vois aucune raison pour laquelle vous ne devriez pas utiliser la correspondance «une page - un bloc de données compressées».

Autrement dit, la taille de page minimale raisonnable est de 16 Ko (avec une marge pour les informations de service). Cependant, une taille de page aussi petite impose des restrictions importantes sur la taille d'enregistrement maximale.

Bien que je ne m'attende toujours pas à des enregistrements de plus d'unités de kilo-octets sous forme compressée, j'ai décidé d'utiliser des pages de 32 Ko (un total de 128 pages par puce).

Résumé:

• Nous stockons les données compressées à l'aide de zlib (dégonfler);
• Pour chaque enregistrement, définissez Z_SYNC_FLUSH;
• Pour chaque enregistrement compressé, nous supprimons les octets finaux (par exemple, 0x00, 0x00, 0xff, 0xff) ; dans l'en-tête indique le nombre d'octets que nous coupons;
• Nous stockons les données dans des pages de 32 Ko; à l'intérieur de la page, il y a un seul flux de données compressées; sur chaque page, nous recommençons la compression.

Et, avant de terminer la compression, je voudrais attirer l'attention sur le fait que nous n'obtenons que quelques octets de données d'écriture, il est donc extrêmement important de ne pas gonfler les informations de service, chaque octet est compté.

Stockage des en-têtes de données

Étant donné que nous avons des enregistrements de longueur variable, nous devons en quelque sorte déterminer l'emplacement / les limites des enregistrements.

Je connais trois approches:

1. Tous les enregistrements sont stockés dans un flux continu, vient d'abord l'en-tête d'enregistrement contenant la longueur, puis l'enregistrement lui-même.
   Dans ce mode de réalisation, les en-têtes et les données peuvent avoir une longueur variable.
   En fait, nous obtenons une liste à lien unique qui est utilisée tout le temps;
2. Les en-têtes et les enregistrements eux-mêmes sont stockés dans des flux séparés.
   En utilisant des en-têtes de longueur constante, nous nous assurons que les dommages à un en-tête n'affectent pas le reste.
   Une approche similaire est utilisée, par exemple, dans de nombreux systèmes de fichiers;
3. Les enregistrements sont stockés dans un flux continu, la limite de l'enregistrement est déterminée par un marqueur (symbole / séquence de caractères, ce qui est / qui est interdit à l'intérieur des blocs de données). Si un marqueur est trouvé à l'intérieur de l'enregistrement, nous le remplaçons par une certaine séquence (échappons-le).
   Une approche similaire est utilisée, par exemple, dans le protocole PPP.

Je vais illustrer.

Option 1:

Tout est très simple ici: connaissant la longueur de l'enregistrement, on peut calculer l'adresse de l'en-tête suivant. Nous passons donc à travers les en-têtes jusqu'à ce que nous rencontrions une région remplie de 0xff (région libre) ou la fin de la page.

Option 2:

En raison de la longueur variable de l'enregistrement, nous ne pouvons pas dire à l'avance le nombre d'enregistrements (et donc les en-têtes) par page dont nous avons besoin. Vous pouvez répartir les en-têtes et les données elles-mêmes sur différentes pages, mais je préfère une approche différente: nous plaçons les en-têtes et les données sur la même page, cependant, les en-têtes (de taille constante) viennent du début de la page et les données (de longueur variable) de la fin. Dès qu'ils se "rencontrent" (il n'y a pas assez d'espace libre pour un nouveau record) - nous considérons que cette page est pleine.

Option 3:

Il n'est pas nécessaire de stocker dans l'en-tête la longueur ou d'autres informations sur l'emplacement des données, il y a suffisamment de marqueurs qui indiquent les limites des enregistrements. Cependant, les données doivent être traitées lors de l'écriture / lecture.
En tant que marqueur, j'utiliserais 0xff (dont la page est remplie après l'effacement), donc la zone libre ne sera certainement pas traitée comme des données.

Tableau de comparaison:

L'option 1 a un défaut fatal: si l'un des en-têtes est endommagé, toute notre chaîne suivante est détruite. D'autres options vous permettent de récupérer une partie des données même en cas de dommages massifs.
Mais ici, il convient de rappeler que nous avons décidé de stocker les données sous forme compressée, et donc nous perdons toutes les données sur la page après l'enregistrement "cassé", donc même s'il y a un moins dans le tableau, nous n'en tenons pas compte.

Compacité:

• dans la première version, nous devons stocker uniquement la longueur dans l'en-tête, si des entiers de longueur variable sont utilisés, alors dans la plupart des cas, nous pouvons le faire avec un octet;
• dans la deuxième option, nous devons stocker l'adresse et la longueur de départ; l'enregistrement doit être de taille constante, j'estime 4 octets par enregistrement (deux octets par décalage et deux octets par longueur);
• , - 1-2%. .

( ). , .

, - - . , , — , , ...

: , , .. , , , — , .

: " — " - .

, , :
.
, erase 1, 1 0, . " " 1, " " — 0.

flash:

1. “ ”;
2. ;
3. “ ”;
4. ;
5. “ ”.

, “ ”, 4 .

“1111” — “1000” — ; , .

, , , , , ( ) .

: .

( ) , . , , .

, , ( , , — ) .

, , , — .

— CRC. , 100% , — $$$2^{-n}$ . , , : , . — .

: 1 , 2 ( narod.ru, ) .

, CRC — . , .

, .

:
$$$10^{-3}$ , :

, — — .

, : , , . , .

, , 32 ( 64 -) .

, , , - 32- (16 , 0.01%; 24 , , ).

: , 4 ? ? , , .

, CRC-32C.
6 22 (, c), 4 655 ( ), 2 .

, , : ?

"" :

• — ( /, , ..);
• deflate zlib "" , , , ( , zlib ).

"" :

• CRC "" , - ( , , , "" );
• , , .

.

: CRC-32C, , flash ( ).

, , , , ( ) .

, .
, - , RAID-6 .
, , , .

, . ?

1. ( - , Raspberry, ...)
   , ;
2. ( - flash- , )
   , ;
3. ;
4. 
   .

( ) . , - .

: , , , ( , ).

, ( ) , , .

• ""
  - , .., , .
  , , ;
• .
  — !
  Magic Number (), ( , ) ;
• ( ) , 1 ;
• .

- . .

Byte order

, , big-endian (network byte order), 0x1234 0x12, 0x34.

- .

32, , 1/4 ( 4 128 ).

( ).

( ), 0 ( 0, — 32, — 64 ..)

(ring buffer), 0, 1, ..., , .

4- , (CRC-32C), ", , ".

( -) :

• Magic Number ( — )
  0xed00 ⊕ ;
• " " ( ).

( deflate). ( ), . ( ).

Z_SYNC_FLUSH, 4 0x00, 0x00, 0xff, 0xff, , , .
( 4, 5 6 ) -.

1, 2 3 , :

• (T), : 0 — , 1 — ;
• (S) 1 7 , "", ;
• (L).

S:

, , :

T, — S, L ( ), — , — , -.

, ( 63+5 ) .

CRC-32C, (init) .

CRC "", (- ) : $$$CRC(init, A || B) = CRC(CRC(init, A), B)$ .
CRC .

.

, 0x00 0xff ( 0xff, ; 0x00 ).

-

.
— - .

( , Linux NOR Flash, )

-

.
.

— .

( ) 1.
( UUID ).

, - .

8 ( + CRC), Magic Number CRC .
"" , , .
, CRC, "". — . — , "" .
, , "" .
zlib ( ).

, , , .

, Z_SYNC_FLUSH., .
( CRC) — (. ).
CRC. — .

( ). — , .
erase. 0xff. - — , ..
, , — ( ).

, - ( , JSON, MessagePack, CBOR, , protobuf) NOR Flash.

, "" SLC NOR Flash.

BER, NAND MLC NOR ( ? ) .

, , FTL: USB flash, SD, MicroSD, etc ( 512 , — "" ) .

128 (16) 1 (128). , , , ( , NOR Flash ) .

- , — , , github.

Conclusion

, .

, : - , , . , () - .

, ? Oui bien sûr. , , . - .

? , , . .

, , " ".

, () , , "" (, , ; ). ( — ) .

, .

Littérature

, .

, , , :

1. infgen zlib. deflate/zlib/gzip. deflate ( gzip) — .