From f00c47faf10c0a89b2a8d69118abdc73b19bc476 Mon Sep 17 00:00:00 2001 From: gilbertchen Date: Fri, 26 Feb 2016 13:45:58 -0500 Subject: [PATCH] Update DESIGN.md --- DESIGN.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/DESIGN.md b/DESIGN.md index c8c45c2..8052791 100644 --- a/DESIGN.md +++ b/DESIGN.md @@ -61,7 +61,7 @@ The first condition guarantees that if a backup procedure references a chunk bef The second condition guarantees that any backup procedure unknown to the fossil deletion step can start only after the fossil collection step finishes. Therefore, if it references a chunk that was identified as fossil in the fossil collection step, it should observe the fossil, not the chunk, so it will upload a new chunk, according to the second fossil access rule. Therefore, if a backup procedure references a chunk before the chunk is marked a fossil, the fossil deletion step will not -delete the chunk until it sees the backup procedure finishes (as indicated by the appearance of a new snapshot file uploaded to the storage). This ensures that scenarios depicted in Figure 2 will never happen. +delete the chunk until it sees that backup procedure finishes (as indicated by the appearance of a new snapshot file uploaded to the storage). This ensures that scenarios depicted in Figure 2 will never happen.