1. CoW Driver is loaded and Snapshot is created. 2. Write I/O comes into the storage array from the host
3. Primary (existing) blocks are copied to Snapshot area for safe keeping
4. Pointers are updated to show snapshot change is in pool area 5. Allow Write I/O request to complete
(4) Update cache map
(1) CoW Driver
(2) Write Request
Primary Disk Area
(5) Allow write to complete (3) Move old blocks to cache
Cache Map
Disk Pool
We will look at snapshots from the sub-systems viewpoint. This is a mountable, usable volume by a third party host. When we do our snapshot, our application server will write the data, we take a snapshot so we now have a view of the data at that point in time. (we don’t have a copy). Snapshots are reliant on the primary logical unit being available. We get our copy on write driver, its quite often inside the subsystem (but there is a software version), our write comes in, we hold the write. Because if we’ve already taken our snapshot we’ve got a pointer to the original data. If we now want to update it, we hold the write coming in on copy on write snapshots. We are going to read the original data and re-write it to our snapshot pool volume or other area. We read the original data and move it. We don’t move it until someone wants to change it.
If data doesn’t get updated we don’t make a
copy. We only copy changed data. The original data gets moved, we now need to update our pointers to say the data that existed is now here. Now we can allow this to write. At that point we’ve now got our consistent usable copy of data at the time we took the snapshot and the application is seeing the new data that it changed after that point in time.