How copy-on-write works
A copy-on-write snapshot is a detailed account of data as it existed at a certain moment. Unlike a mirror, a copy-on-write is not a copy of the data, but a specialized account of it.
The copy-on-write process works as follows: when a snapshot is required, any unfinished transactions or changes to the source data are allowed to complete, but new changes are temporarily stalled. The source is momentarily idled (made quiescent). Once the copy-on-write is activated, new transactions or changes (writes) to the source data are allowed to take place. However, the copy-on-write process briefly intercepts or holds the first write request that is issued for any particular block of data. While it holds those requests, it copies to cache the blocks affected by those writes, and keeps a record of the cached blocks. In other words, it reads each source block that is about to change for the first time. Then it copies the block's current data to cache, and records the location and identity of the cached blocks. Then the intercepted writes are allowed to take place in the source blocks.
Figure: Copy-on-write process shows the copy-on-write process.
The following table lists the phases that have been depicted in the diagram:
Phase | Action |
|---|---|
Phase 1 | Image of source data is frozen; copy-on-write is activated. |
Phase 2 | New write requests to s4, s7, s8 are held by copy-on-write process (see arrows). |
Phase 3 | Copy-on-write process writes contents of blocks s4, s7, and s8 to cache. These blocks write to cache only once, no matter how many times they change in the source during the snapshot. |
Phase 4 | Copy-on-write process keeps a record of the number of writes to cache. |
Phase 5 | Write requests are now allowed to take place. |
The immediate results of the copy-on-write are the following: a cached copy of the source blocks that were about to change (phase 3), and a record of where those cached blocks are stored (phase 4).
The copy-on-write does not produce a copy of the source. It creates cached copies of the blocks that have changed and a record of their location. The backup process refers to the source data or cached data as directed by the copy-on-write process.
Figure: Backing up a copy-on-write shows the process for backing up a copy-on-write snapshot.
The following table lists the phases that have been depicted in the diagram:
Phase | Action |
|---|---|
Phase 1 | Backup reads source data from s0, s1, s2, s3 |
Phase 2 | At s4, copy-on-write tells backup to read c0 instead of s4 |
Phase 3 | Next, the backup reads s5 and s6 from the source. |
Phase 4 | At s7 and s8, copy-on-write tells backup to read c1, c2 instead of s7, s8. |
Phase 5 | Backup continues reading of the source or cache, as directed by copy-on-write. |
Phase 6 | When backup completes, backup data is identical to original source. |
As this diagram shows, an accurate backup image is obtained by combining the unchanged portions of the data with the cache. When a backup of the snapshot begins, the backup application copies the source data (phase 1) until it encounters a block that changed after the copy-on-write process started. The copy-on-write tells the backup to skip that changed block and read in its place the cached (original) copy (phase 2). The backup application continues copying source data (phase 3) until it comes to another changed block. Cache is read again (phase 4) as the copy-on-write process dictates. The backup, when finished, is an exact copy of the source as it existed the moment the copy-on-write was activated.