When an administrator wants to reduce the client visible file system size and potentially reclaim space to the underlying storage pool, a manual shrink operation can be initiated. This is done in the same way as a manual extension, by changing the file system size in Unisphere to the new size. After the shrink operation completes, clients will see the new advertised file system size.

Manual shrink operations may also return unused space to the storage pool, depending on the size of the shrink and the current allocation of the file system. Manual shrink operations can only return space to the pool if the file system is shrunk into allocated space and will return to the pool a maximum of the difference between the allocated space and the new Size after shrinking. To illustrate this, consider this file system: size = 3 TB, allocated = 1 TB, used = 500 GB. Manually shrinking this file system from 3 TB to 1 TB would return no space to the pool, as the file system was not shrunk into allocated space. However, shrinking from 3 TB to 0.9 TB could potentially return up to 0.1 TB to the pool, depending on the existence of snapshots.

Figure 14.    Manual shrink confirmation

It is never possible to shrink into used space, so attempting to reduce the file system size to less than 500 GB would fail in this example. The figure below shows the confirmation message when attempting to shrink a file system in Unisphere, which will calculate the expected amount of space to be reclaimed to the storage pool depending on the current allocation of the file system and requested size. This message indicates that the amount reclaimed depends on the existence of snapshots. This is because snapshots of the file system are required to preserve a view of the file system associated with a particular point in time, and therefore the system cannot allow any blocks associated with an existing snapshot to be reclaimed to the storage pool, even if that space is unused at the current point in time.

For example, suppose a snapshot is taken of a fully allocated 100 GB file system. After taking the snapshot, the administrator immediately shrinks the file system to 80 GB. Because the snapshot must preserve the point-in-time view of the 100 GB file system, the file system shrink operation succeeds in reducing the size of the current production file system but does not return any space to the storage pool. Despite being shrunk from the production file system, the 20 GB is still associated with the snapshot taken previously, and therefore must be preserved in the event the snapshot needs to be restored in the future. In this circumstance, the confirmation message shows only a very small amount of metadata space to be reclaimed.

Figure 15.    Manual shrink confirmation with snapshot

This is an extreme example used to illustrate the potential effect of snapshots on file system shrink operations, rather than a typical case. The amount of space reclaimed is a function of the amount of changed data since the last snapshot was taken. The less data that has changed since the last snapshot was taken, the larger the apparent disparity in shrunk data and reclaimed space. In the example above, notice that the shrink operation was initiated immediately after taking the snapshot, meaning the snapshot and production file system contained the same data at the time of the shrink operation. Because all 20 GB being shrunk was also tied to the snapshot, none of this space could be returned to the pool. However, if the shrink operation were instead initiated later, after some changes had been made to the data, the snapshot and current file system would no longer be identical. In this case the file system would contain blocks not also associated with any snapshot, and therefore eligible to be reclaimed as part of the shrink operation. For more information about snapshots, reference the Dell Unity: Snapshots and Thin Clones white paper on Dell Technologies Info Hub.