aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorn-peugnet <n.peugnet@free.fr>2021-09-29 18:39:12 +0200
committern-peugnet <n.peugnet@free.fr>2021-09-29 18:39:12 +0200
commit98e51364c7378622f8bbf5b580865c8bf6efc965 (patch)
tree65908f104ff4b7b7d97f5dc51d6565da4c1efd63
parente16bc630d3cc15da269c5cdaeaa525eea5bd0c74 (diff)
downloaddna-backup-98e51364c7378622f8bbf5b580865c8bf6efc965.tar.gz
dna-backup-98e51364c7378622f8bbf5b580865c8bf6efc965.zip
fix typos in README
-rw-r--r--README.md43
1 files changed, 22 insertions, 21 deletions
diff --git a/README.md b/README.md
index 7a13ded..d246465 100644
--- a/README.md
+++ b/README.md
@@ -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_