Rehydration is an option, and is not enabled by default. Rehydration works by marking a tiered object to be rehydrated when the object is first read. This means that the first read, and any read prior to rehydration, will be serviced directly from the cloud pool, but that reads subsequent to the object being rehydrated will be serviced from the local disk pool. Rehydration occurs in the background and is managed by the Storage Tiering service. Subsequent reads, after the object has been rehydrated, will extend the rehydration period (8.0+). When the time between the last read and the current time is > the rehydration period, Storage Tiering will mark the IF on the local disk pool as garbage. It is not until GC inspects that object that the data will actually be deleted from disk and free the capacity.
Tiering and Service Plans can be configured to create quite a bit of churn in the form of additional object copies in various pools, and can create a tremendous amount of backlog for GC. When this happens consumed capacity can bloat well beyond the expected capacity. This can be especially problematic on systems with high object counts because GC has to visit every object on every pass, and can take days or weeks to complete a pass when the system has billions of objects and there is a relatively high percentage of the data that is considered garbage. For this reason it is important to carefully think through and plan Service Plan changes before implementing them, and to try to avoid frequent changes to Service Plans.
8.2 plans to improve the situation by enhancing all services do their own GC inline, and not just marking them as garbage for the GC service to clean up later. They will also be adding an option to perform interactive (user requested) deletions inline.