When an update is received for a previously written block of data, the system determines if the overwrite is for a block which has space savings or not. The data is also passed through the data reduction logic to determine if any space savings can be achieved. If the new block of data deduplicates to a known pattern, the private space within the resource is updated with the new pattern information. If the now outdated block of data had compression savings or was written to the Pool in its original form, these blocks are freed within the resource for reuse. If deduplication savings cannot be achieved the data is sent though the compression logic.

If compression can reduce the size of the data, the system needs to determine where to store the block of data within the Pool. If the amount of compression savings is now less than the last time the data was written, then new space must be allocated within the storage resource to store the new data size. If the dataset size hasn’t changed or is smaller than it was previously, then a write to an already allocated block may occur. This logic prevents causing fragmentation in the resource, which helps with performance and space savings. If a new block is allocated, the previously used block is freed for reuse. If no deduplication or compression savings can be achieved, the data is written in the Pool at its original size, and may overwrite the original data for the resource.

In the background, the old locations that are no longer needed are freed by a cleanup process and can be reused. This process also frees blocks no longer in use by the storage resource and its Snapshots or Thin Clones. If enough space is freed within a 256 MB slice, the slice can be freed back to the Pool.