Here's something I bet you've never thought of before: how can a volume snapshot, which is a picture of state of the volume, be stored in the same volume? It's kind of like trying to take a picture of your entire self, hand included, while holding the camera.
Think about it. A volume snapshot creates pointers to all the blocks in the volume, and retains them no matter what happens to the active data. If you write a couple new blocks to identify within the volume that there is a new snapshot, along with the timestamp, etc, that has changed the volume. That data must be written somewhere new since the old space is all protected. The entire volume's space is protected. Every new snapshot would make the volume read-only until the volume is expanded.
Even crazier: since snapshots reside inside the volume, this means when you take a second volume snapshot, you're taking a snapshot of a snapshot. Whoa.
Solution:
Volume snapshots don't take a snapshot of the whole volume: white space is not included. This means that volume snapshots only protect the blocks that are currently occupied with data: the rest of the space carved out for the volume is not part of the deal.
Let's say you have a 20GB volume with a 1GB LUN inside. Take a volume snapshot: the largest that snapshot can get is 1GB, and if your LUN changes but does not grow, only 2GB of your 20GB will be occupied be data.
Let's say you have a 20GB volume with 4 1GB LUNs inside. Take a volume snapshot: the largest that snapshot can get is 4GB, since that is the sum total of space occupied by data. Let's say that happens, and our original 4 LUNs are all 1GB but all their data has changed. The total space occupied by data is 8GB. If you take a snapshot of the volume now, it will save the state of both the LUNs and snapshots in the volume, since snapshots do indeed count as data. The largest your new snapshot can grow is 8GB.
A note of interest is that the snapshot info (name of snapshot, date taken, block pointers (aka inode tables), file allocation, and metadata like ACL's) all resides inside the volume.
Think about it. A volume snapshot creates pointers to all the blocks in the volume, and retains them no matter what happens to the active data. If you write a couple new blocks to identify within the volume that there is a new snapshot, along with the timestamp, etc, that has changed the volume. That data must be written somewhere new since the old space is all protected. The entire volume's space is protected. Every new snapshot would make the volume read-only until the volume is expanded.
Even crazier: since snapshots reside inside the volume, this means when you take a second volume snapshot, you're taking a snapshot of a snapshot. Whoa.
Solution:
Volume snapshots don't take a snapshot of the whole volume: white space is not included. This means that volume snapshots only protect the blocks that are currently occupied with data: the rest of the space carved out for the volume is not part of the deal.
Let's say you have a 20GB volume with a 1GB LUN inside. Take a volume snapshot: the largest that snapshot can get is 1GB, and if your LUN changes but does not grow, only 2GB of your 20GB will be occupied be data.
Let's say you have a 20GB volume with 4 1GB LUNs inside. Take a volume snapshot: the largest that snapshot can get is 4GB, since that is the sum total of space occupied by data. Let's say that happens, and our original 4 LUNs are all 1GB but all their data has changed. The total space occupied by data is 8GB. If you take a snapshot of the volume now, it will save the state of both the LUNs and snapshots in the volume, since snapshots do indeed count as data. The largest your new snapshot can grow is 8GB.
A note of interest is that the snapshot info (name of snapshot, date taken, block pointers (aka inode tables), file allocation, and metadata like ACL's) all resides inside the volume.
No comments:
Post a Comment