More copy on write

From Robs_Wiki
Revision as of 11:44, 28 January 2020 by Qadmin wiki (talk | contribs) (Created page with "There are two very different ways to create snapshots: copy-on-write and redirect-on-write. <br /> What all snapshot types have in common is that they are virtual copies not p...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

There are two very different ways to create snapshots: copy-on-write and redirect-on-write.
What all snapshot types have in common is that they are virtual copies not physical copies. A snapshot has two primary purposes: easy recovery of deleted or corrupted files, and a source for replication or backup. In order for the snapshot to protect against media failure, you must replicate or back it up to some other device. In other words, you must make a physical copy.

Copy-on-write
Consider a copy-on-write system, which copies any blocks before they are overwritten with new information. If a block in a protected entity is to be modified, the system will copy that block to a separate snapshot area before it is overwritten with the new information. This approach requires three I/O operations for each write: one read and two writes. Prior to overwriting a block, its previous value must be read and then written to a different location, followed by the write of the new information

Redirect-on-write
A redirect-on-write system uses pointers to represent all protected entities. If a block needs modification, the storage system merely redirects the pointer for that block to another block and writes the data there (i.e. it redirects on writes).

The redirect-on-write system uses 1/3 the number of I/O operations when modifying a protected block, and it uses no extra computational overhead reading a snapshot. Copy-on-write systems can therefore have a big impact on the performance of the protected entity.