Model: fable-5-1
This commit is contained in:
+15
-5
@@ -1,8 +1,11 @@
|
||||
# vaultik architecture
|
||||
|
||||
This document describes how the `vaultik` code is organised. It covers the
|
||||
packages, how they are wired together, and what happens during a backup, a
|
||||
restore, a verify and a prune.
|
||||
This document describes how the `vaultik` code is organised. It covers three
|
||||
things:
|
||||
|
||||
- the packages
|
||||
- how they are wired together
|
||||
- what happens during a backup, a restore, a verify and a prune
|
||||
|
||||
Two other documents cover the stored data:
|
||||
|
||||
@@ -170,11 +173,18 @@ The walk handles each kind of entry differently:
|
||||
Data is stored once at two levels.
|
||||
|
||||
- **Files.** A file is not read again when its record in the index still matches
|
||||
it. The record matches when the size, modification time, mode, owner, group
|
||||
and link target are all the same.
|
||||
it.
|
||||
- **Chunks.** A chunk is named by the SHA-256 hash of its content. A chunk whose
|
||||
hash is already in the index is not stored again.
|
||||
|
||||
A file's record matches when all of these are unchanged:
|
||||
|
||||
- the size
|
||||
- the modification time
|
||||
- the mode
|
||||
- the owner and group
|
||||
- the link target
|
||||
|
||||
One case overrides the file check. A file is read again when it lists a chunk
|
||||
that no uploaded blob holds. This happens after the only snapshot that used
|
||||
such a blob is removed. `loadFilesToRechunk` finds these files.
|
||||
|
||||
Reference in New Issue
Block a user