To enable the snapshot to survive across panics and power failures, we need to store the map and modified blocks in persistent storage. In addition, we have to keep the map and snapshot blocks consistent. i.e., whenever a COW push occurs, the update of the map and copy of the contents of the original block to snapshot disk has to be atomic. This atomicity can be achieved in two ways.
1. Ordered Writes: Here, the original block is first copied to the snapshot block and then the map block is written to the disk. Even if power fails in between, on the next write to the same block of the original disk, a COW push will be done as the map for that block has not yet been updated. The opposite order is problematic.
2. Logging: In this case, intentions are logged onto the log disk first and the original disk updates can be done in background. This is called as REDO logging [2]. In case of a crash, when the machine comes up, an user application scans through and replays the log (the data is taken from the log and written to the disk). Thus the snapshot data remains consistent.
Out of the above two methods, method 2 is more efficient. This is because the original disk writes can resume immediately after logging the transaction onto the log disk. And log disk writes are more efficient as they are written sequentially. Actual updates of map and the snapshot block can be done in background. Hence, the delay introduced for original writes will be smaller in the second method. In our implementation, we use data logging.