The concept here is that a snapshot can become as large as the original dataset in the volume (100%). Remember that the space occupied by data in the volume is the sum of the existing LUNS/Qtrees and any snapshots that exist in that volume. Empty space in the volume is ignored by snapshots.
Here's the important background idea: WAFL does not update-in-place when existing data is changed. This means that for a normal LUN that has no snapshots, when data changes, it is written to a new location (total space occupied increases) and then the old data is deleted (total space occupied goes back to pre-change levels).
Illustration: If in a LUN with 6GB of data a 4KB block is changed, the sum total of space occupied by data rises to 6GB + 4KB, then back to 6GB as the out of date 4KB block is deleted and reclaimed. WAFL handles this so quickly that your LUN effectively does not increase in size. This is a great advantage for WAFL because update in place can cause data corruption.
This concept is essential to understanding how snapshots work in ONTAP. Let's go back to our 6GB LUN with a 4KB change: WAFL writes the new 4KB data to new, unoccupied space and the snapshot is left occupying the space that would be otherwise deleted. So as data changes, it is not actually the snapshot that is allocated more space, but its existence means that the space that could be reclaimed is now solely assigned to the snapshot. So any data that is only assigned to the snapshot is considered occupied by the snapshot. In this example, the snapshot would be considered to be 4KB in size.
The size taken up by the snapshot increases in concert with the changes to the original LUN: 500MB of changes to the original LUN means that the snapshot will grow from 0 to 500MB in size. For 20GB volume that has 6GB of data (including LUNs and other snapshots), the next snapshot can grow as large as 6GB, making the sum total of the original data and the new snapshot 12GB.
You can find commands to control snapshots here.
Here's the important background idea: WAFL does not update-in-place when existing data is changed. This means that for a normal LUN that has no snapshots, when data changes, it is written to a new location (total space occupied increases) and then the old data is deleted (total space occupied goes back to pre-change levels).
Illustration: If in a LUN with 6GB of data a 4KB block is changed, the sum total of space occupied by data rises to 6GB + 4KB, then back to 6GB as the out of date 4KB block is deleted and reclaimed. WAFL handles this so quickly that your LUN effectively does not increase in size. This is a great advantage for WAFL because update in place can cause data corruption.
This concept is essential to understanding how snapshots work in ONTAP. Let's go back to our 6GB LUN with a 4KB change: WAFL writes the new 4KB data to new, unoccupied space and the snapshot is left occupying the space that would be otherwise deleted. So as data changes, it is not actually the snapshot that is allocated more space, but its existence means that the space that could be reclaimed is now solely assigned to the snapshot. So any data that is only assigned to the snapshot is considered occupied by the snapshot. In this example, the snapshot would be considered to be 4KB in size.
The size taken up by the snapshot increases in concert with the changes to the original LUN: 500MB of changes to the original LUN means that the snapshot will grow from 0 to 500MB in size. For 20GB volume that has 6GB of data (including LUNs and other snapshots), the next snapshot can grow as large as 6GB, making the sum total of the original data and the new snapshot 12GB.
You can find commands to control snapshots here.
No comments:
Post a Comment