How to store snapshots commonly implemented

Storage snapshots Common implementations there are two main techniques for implementing snapshots at the moment, one is copying on the first write (copy Onfirst WRITE,COFW), sometimes abbreviated to write-time replication (Copyon write,cow). That is, when data is first written to a storage location, the original content is read first, written to another location (the storage space reserved for the snapshot, which we call the snapshot space), and then the data is written to the storage device. The next write operation for this location will no longer perform a write-time copy operation.       This technology is often used in computer-related technology, the basic principle is very similar, but the object is different, applicable to the occasion. As we know from the cow execution process, this implementation will require a read operation (read the original location data) for the first time to write to a storage location, two write operations (write the original location and write-snapshot space), and if the write is frequent, this would be very time-consuming for IO. Therefore, it is inferred that the snapshot implementation technique in this way is an ideal choice if the majority of the I/O on a volume is expected to be predominantly read and the write operation is less, because the completion of the snapshot requires less time. In addition, if an application is prone to write hotspots, that is, only for a limited range of data to write operations, then cow Snapshot implementation is also a more ideal choice. Because its data changes are limited to one scope, a write-time copy operation occurs only once for multiple writes of the same data. The following figure is a schematic of the copy at write time:
But the drawbacks of this approach are also very obvious. If the write operation is too fragmented and frequent, the overhead of cow is not negligible, and sometimes even unacceptable.       Therefore, when applied, it is necessary to evaluate the usage scenarios of the application system synthetically to determine whether the snapshot of this method is applicable. Another technique in snapshot implementation is I/O redirection (I/O Redirect). REDIRECT the read-write operation to another storage space. During a snapshot generation, all writes are redirected to another media, if the read operation requires read redirection, it is necessary to read redirects to locations where there has been write redirection, depending on whether the read location has a write redirect since the last snapshot, otherwise no read orientation is required. When you want to create a snapshot, a snapshot generation process is completed by copying the data from the original media corresponding to all the redirected write data since the last snapshot to generate a snapshot of this point-in-time, and then writing the redirected write data back to the appropriate location on the source media. The following illustration shows the process of performing IO redirection.
From the above process, the key performance impact is the four I/O operations at the time of snapshot generation (read source media once, write snapshot data Once, read snapshot media once, write source media once), and the other is the computational work of redirection. This approach may seem to be more I/O operations at the end of the snapshot generation, but given that this action occurs when a snapshot is generated, especially when snapshot generation can sort I/O operations, so that the read and write to the media is better optimized, so the impact is very small. For the computing power of the current, the computational operation of redirection will not become a bottleneck problem of performance. As a result, this snapshot implementation has little impact during non snapshot execution. This approach is therefore better suited for write-intensive (write-intensive) storage systems. The following figure is a schematic diagram of the snapshot generation process:
SNIA describes the implementation of the snapshot as: Mirror separation (split mirror), change blocks (changed block), concurrency (concurrent) three broad categories. The latter two in the implementation of the essence is write-time replication and I/O redirection. For the split mirror, because of its flexibility and overhead, it is not practical in the actual storage system. [This post is finally edited by spring 2015-08-07 09:46:28]


======================================================================

Copy write and redirect write snapshots
Copy-on-write (COW) Copy write snapshot
Cow snapshots need to consume some storage space-create snapshot volumes. When we create a snapshot of a data volume, the reserved space is used to hold the old data updated by the changed data. The cow snapshot creates only the pointer information (metadata) that describes the location of the source block in the initialization process, rather than copying the source data block completely. So the initialization process can be done almost instantaneously, with little impact on the system.
The cow snapshot tracks the write operations and data block changes of the data volume. When a block changes, before overwriting the old data, the old data of the block is first copied to the reserved snapshot volume, which occurs only when the first write operation is requested at the corresponding block position of the data volume. This process ensures that the data from the snapshot remains exactly the same as the exact point at which the snapshot was launched. This process also describes the meaning of the name "Copy on Write".
If we need to access the snapshot data at a point in time, read the unchanged block directly from the data volume, and read the changed and replicated blocks from the snapshot space. From the moment the snapshot is created, each snapshot tracks the metadata information that describes the block changes.
The main advantage of cow snapshots is the efficient use of space, because the snapshot volumes only need to retain the data blocks that have changed, much smaller than the data volumes. But we also know that cow snapshots have a disadvantage, which can cause data volume performance to drop because, after the snapshot is created, the write operation on the data volume adds a waiting procedure-that is, the process of copying old blocks of data to the snapshot volume. Another key issue is that each snapshot volume must rely on a complete data volume.
Redirect-on-write (ROW) redirect Write snapshots
"Row redirection write" and "cow copy write" are relative concepts that can avoid performance losses caused by two of write operations. Row, like cow, has a very high efficiency in space use. What is that? The row snapshot avoids the loss of write performance. The reason for this is that row redirects write requests to the data volume to the storage space reserved by the snapshot, while the write redirection design reduces the number of operations that require two writes to a single write. We know that cow's two writes include: 1, write old data to the snapshot volume, 2, write new data on the data volume. and row only writes new data one step.
With a row snapshot, the data volume holds the old data from the previous snapshot point, and the new data is eventually stored in the reserved snapshot space. There is also a complex problem with the deletion of snapshots. The data on the deleted snapshot must be copied to the original data volume, and the consistency fallback is done. The more snapshots you create, the more complex the maintenance snapshots will increase exponentially. These complexities include access to raw data, tracking of snapshot data and raw data volumes, and data adjustments after snapshot deletion. Another serious problem that is directly raised is that the raw dataset produces a lot of fragmentation.