Filter
Top Products
Chapter 6 Checkpoints/Snapshots 6-9
Another example is when a hard-link is created in a directory named dst to a file
residing in a directory called src. First, a new directory is inserted in dst. However,
since volume is checkpointed, a copy of corresponding disk block is made first, and
then the disk block is modified. When accessing the checkpoint version (and thus
accessing the copied block), the old directory content (without the new entry) is
seen. Next, the target inode is modified so the link count reflects the new directory
entry (pointing to it by incrementing it). This will cause the corresponding disk
block to inode data be modified and the copy containing old content will be
assigned to checkpoint. Again, for someone accessing the checkpoints, the inode
seems to be unchanged and everything remains perfectly consistent both in
checkpoint and live file systems.
6.1.2.4 Checkpoint Deletion
When a checkpoint is to be deleted, a flag is set in the entry for that checkpoint in
the checkpoint control page. Later the cleaner thread for checkpoint filesystem
catches the flag and scans the entire mapping for each block in filesystem and if
there is a mapping entry for the checkpoint and if the previous checkpoint has no
mapping for the block, then the entry is moved to the entry for the previous
checkpoint. Otherwise if the mapping is not SFS2CP_ALLO_MARKER, the block is
freed. Then all of the entries for checkpoint after the one that is to be deleted are
moved to the left.
For example in Figure 6-2, when deleting ckpti-1, m is moved to the entry for ckpti-
2 and all of the entries after ckpti-1 are moved to the left (this operation is done
logically in the checkpoint stack, so the actual entries are not moved, only block
ownership will be delegated). So ckpti replaces ckpti-1. After changing the
mappings, checkpoint stack is also updated similar to what has been done for
checkpoint mapping entries. So after deleting ckpti-1, the mapping entries for block
n will be as in Figure 6-6.