diff options
author | n-peugnet <n.peugnet@free.fr> | 2021-09-29 18:39:12 +0200 |
---|---|---|
committer | n-peugnet <n.peugnet@free.fr> | 2021-09-29 18:39:12 +0200 |
commit | 98e51364c7378622f8bbf5b580865c8bf6efc965 (patch) | |
tree | 65908f104ff4b7b7d97f5dc51d6565da4c1efd63 | |
parent | e16bc630d3cc15da269c5cdaeaa525eea5bd0c74 (diff) | |
download | dna-backup-98e51364c7378622f8bbf5b580865c8bf6efc965.tar.gz dna-backup-98e51364c7378622f8bbf5b580865c8bf6efc965.zip |
fix typos in README
-rw-r--r-- | README.md | 43 |
1 files changed, 22 insertions, 21 deletions
@@ -5,7 +5,7 @@ _Deduplicated versioned backups for DNA._ ## Details (FR) - +<!-- LTeX: language=fr --> Le système part du principe qu'on a une copie des données stockées en ADN sur un support de stockage classique : le _repo_. @@ -43,7 +43,7 @@ repo/ └── recipe ``` -Pour un repo d'une taille totale de 401 Mio: +Pour un repo d'une taille totale de 401 Mio : ``` /tmp/test-1/00000/recipe 5076011 (1.20%) @@ -57,12 +57,12 @@ Pour un repo d'une taille totale de 401 Mio: - On considère que le _repo_ est toujours présent lors d'une écriture (_commit_). - Le _repo_ peut être reconstruit à partir des données présentes dans le _DNA-Drive_. -- Les _hashes_ ne sont pas écrits en ADN car ils peuvent être reconstruits à +- Les _hashes_ ne sont pas écrits en ADN, car ils peuvent être reconstruits à partir des données des _chunks_. - L'ensemble des données écrites en ADN sont compressées, pour le moment via _ZLib_. -- Les metadonnées sont stockées de manière incrémentale, chaque version stocke - donc ses metadonnées sous la forme de delta par rapport à la version +- Les métadonnées sont stockées de manière incrémentale, chaque version stocke + donc ses métadonnées sous la forme de delta par rapport à la version précédente. On imagine le _DNA-Drive_ comme un segment de _pools_ : @@ -75,47 +75,47 @@ On imagine le _DNA-Drive_ comme un segment de _pools_ : (recipe+files) ``` -### Commit algorithm +### Commit algorithme 1. Chargement des métadonnées du _repo_ afin de reconstruire en mémoire l'état de la dernière version : - Reconstruction de la _recipe_ à partir des deltas de chaque version. - - Reconstruction du listing des fichiers à partir des deltas de chaque + - Reconstruction du listage des fichiers à partir des deltas de chaque version (fichier _files_). - Reconstruction en mémoire des _maps_ de _fingerprints_ et de _sketches_ à partir des fichiers _hashes_ de chaque version. -2. Listing des fichiers de la _source_. -3. Concatenation de l'ensemble des fichiers de la source en un disque virtuel +2. Listage des fichiers de la _source_. +3. Concaténation de l'ensemble des fichiers de la source en un disque virtuel continu. -4. Lecture du _stream_ de ce disque virtuel et découpage en _chunk_ (de 8kio +4. Lecture du _stream_ de ce disque virtuel et découpage en _chunk_ (de 8 Kio actuellement). -5. Pour chaque _chunk_ du _stream_: +5. Pour chaque _chunk_ du _stream_ : 1. Calculer sa _fingerprint_ (hash classique), si elle est présente dans la - _map_ : le stocker de manière dédupliquée (sous la forme d'identifiant + _map_ : le stocker de manière dé-dupliquée (sous la forme d'identifiant faisant référence au _chunk_ trouvé dans la map). 2. Sinon, calculer son _sketch_ (hash de ressemblance), - si il est présent dans la _map_, le stocker sous la forme de delta (calcul + s'il est présent dans la _map_, le stocker sous la forme de delta (calcul de sa différence par rapport au _chunk_ trouvé dans la map). 3. Sinon, le stocker sous la forme de nouveau bloc (ajout de sa _fingerprint_ et de son _sketch_ dans les _maps_ et stockage du contenu complet dans un nouveau _chunk_). -6. Calcul des différences entre la nouvele version et la précédente pour les +6. Calcul des différences entre la nouvelle version et la précédente pour les métadonnées (_files_ et _recipe_) et stockage des deltas ainsi obtenus. -### Restore algorithm +### Restore algorithme 1. Chargement des métadonnées du _repo_ afin de reconstruire en mémoire l'état de la dernière version : - Reconstruction de la _recipe_ à partir des deltas de chaque version. - - Reconstruction du listing des fichiers à partir des deltas de chaque + - Reconstruction du listage des fichiers à partir des deltas de chaque version. 2. À partir de la _recipe_, reconstruire le disque virtuel (sous la forme d'un _stream_). -3. Découper ce _stream_ en fonction du listing des fichiers (_files_) et - réécrire les données dans les fichiers correspondants dans le repertoire +3. Découper ce _stream_ en fonction du listage des fichiers (_files_) et + réécrire les données dans les fichiers correspondants dans le répertoire _destination_. -### Restorer sans le _repo_ +### Restaurer sans le _repo_ #### Reconstruction complète du _repo_ @@ -124,7 +124,7 @@ _DNA-Drive_. #### Restauration de la dernière version -Il est possible de ne restaurer que ka dernière version en lisant dans un +Il est possible de ne restaurer que la dernière version en lisant dans un premier temps le _pool_ de versions et les quelques _pools_ de métadonnées (environ 2% de la totalité des données écrites), puis en lisant tous les _pools_ contenant des _chunks_ référencés par la _recipe_ de cette version. @@ -135,10 +135,11 @@ Il pourrait être possible (pas pour le moment) de ne restaurer qu'un seul fichi d'une version en ayant moins de données à lire que pour restaurer la version complète. -Pour cela, il faudrait en plus stocker en ADN un mapping _chunk_ décompressé -> +Pour cela, il faudrait en plus stocker en ADN un mapping _chunk_ décompressé → _pool_ contenant ce _chunk_ et ainsi n'avoir à lire que les _pools_ contenant des _chunks_ de ce fichier. +<!-- LTeX: language=en --> ## Build instructions _Classical go_ |