Unitek NetApp Training Blog

We have been looking at snapshot space management primarily from a NAS perspective.  From this perspective the primary technique used to deal with storage tied to the snapshots is the mechanism of the snapshot reserve.  And we have seen that all the snapshot reserve really does is set aside some space when the volume is created so that it will be available for overwrites of blocks that are tied to snapshots.  Essentially this is used to hide space usage from snapshots, but it does not affect our ability to execute a snapshot.

The situation with SAN and LUNs drives off of these ideas, but is slightly more complex.  We will be looking at this from the perspective of traditional volumes and some new capabilities available with flexible volumes.

Essentially, the problem is the same.  Once blocks in the WAFL file system are part of a snapshot they are protected.  They become read-only blocks, so to do updates we have to be able to supply unused blocks.  There is more than one way to do this.

In the world of traditional volumes we have limited options.  Traditional volumes are also aggregates.  They own their own disks and the problem has to be resolved within this context.  This is done through space reservations and the fractional reserve.

Here is an example of the lun setup script.  One of the prompts asks do we want the LUN to be space reserved and gives the explanation that this will guarantee that writes to the LUN will never fail.

Why do we need such a guarantee?  If we are not using snapshots then we really don’t need this guarantee.  But if we are taking snapshots then some blocks within the LUN will become read-only when the snapshot is taken.  Since the host operating system is not aware of the snapshot, Data ONTAP must have a pool of blocks to supply the host for overwriting blocks held in snapshots.  This pool is set aside when the LUN is created when we say “yes” to the space reserved prompt.

By default the size of this pool is equivalent to the size of the LUN.  This means the volume must be large enough to contain both the LUN, the space reserved for overwrites and the blocks tied up by snapshots.  To support a 100 MB LUN we would need volume that was at least 200MB plus some amount to support the blocks tied up in snapshots.

We can adjust the space reservations with a parameter called the fractional reserve.  The fractional reserve is applied to space reservations.  It is set to 100% by default so the block pool is able to support the LUN even if the host were to update every block in the LUN while simultaneously every block in the LUN were locked up in one or many snapshots.  This is why we can say that data writes will never fail.  If the number of blocks locked by a snapshot were to set up the situation where the number of free blocks left in the volume were less than the amount of space reserved then the snapshot would fail.  The number of free blocks in the volume would never be less than the number of blocks allocated to the LUN.

We can reduce the amount of space reserved by adjusting fractional reserve.  The following command would set the fractional reserve to 70% instead of 100% for vol2:

This decreases the amount of space reserved, but it is possible to create a situation where there may not be free blocks available in the volume when the host tries to update a block in the LUN.  If this happens the write will fail.

With traditional volumes, space reservations combined with a fractional reserve of 100% was the only way we could be sure LUN writes would never fail.  With flexible volumes and Data ONTAP 7.2, we have some new options.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.