Object store space reclamation in tiered filesystems

Content Software for File User Guide

Part Number

Object store space reclamation in tiered filesystems is an important process that efficiently manages data stored on object storage.

In the Content Software for File system, object store space reclamation is only relevant for object store buckets used for tiering (local) and not for buckets used for backup only (remote). Content Software for File organizes files into 64 MB objects for tiering. Each object can contain data from multiple files. Files smaller than 1 MB are consolidated into a single 64 MB object. For larger files, their parts are distributed across multiple objects. As a result, when a file is deleted (or updated and is not used by any snapshots), the space within one or more objects is marked as available for reclamation. However, the deletion of these objects only occurs under specific conditions.

Deleting related objects happens when all associated files are deleted, allowing for complete space reclamation within the object or during the reclamation process. Reclamation entails reading an eligible object from object storage and packing the active portions (representing data from undeleted files) with sections from other files that must be written to the object store. The resulting object is then written back to the object store, freeing up reclaimed space.

Content Software for File automates the reclamation process by monitoring the filesystems. When the reclaimable space within a filesystem exceeds 13%, the reclamation process begins. It continues until the total reclaimable space drops below 7%. This mechanism prevents write amplifications, allows time for higher portions of eligible 64 MB objects to become logically free, and prevents unnecessary object storage workload for small space reclamation. It's important to note that reclamation is only executed for objects with reclaimable space exceeding 5% within that object.

To calculate the amount of space that can be reclaimed, consider the following examples:
  • If we write 1 TB of data, and 15% of that space can be reclaimed, we have 150 GB of reclaimable space.
  • If we write 10 TB of data, and 5% of that space can be reclaimed, we have 500 GB of reclaimable space.
The starting point for the reclamation process differs in each example. In example 1, reclamation begins at 130 GB (13%), while in example 2, it doesn't start. This is important to note because even though there is more total reclaimable space in example 2, the process starts later.

For regular filesystems where files are frequently deleted or updated, this behavior can result in the consumption of 7% to 13% more object store space than initially expected based on the total size of all files written to that filesystem. When planning object storage capacity or configuring usage alerts, it's essential to account for this additional space. Remember that this percentage may increase during periods of high object store usage or when data/snapshots are frequently deleted. Over time, it will return to the normal threshold as the load/burst is reduced.

Note: If the filesystem was created from a snapshot, only the data uploaded to the object store after the new filesystem was created can be reclaimed. Pre-existing data from the original snapshot is unreclaimable. To ensure all data is reclaimable, migrate the restored filesystem to a new bucket. For details, see Attach or detach object store buckets.
Note: If tuning of the system interaction with the object store is required (such as object size, reclamation threshold numbers, or the object store space reclamation is not fast enough for the workload) contact customer support.

View object store bucket capacity details

Run the weka fs tier capacity command to retrieve a comprehensive listing of data capacities associated with object store buckets per filesystem.

Note: If the filesystem was created from an uploaded snapshot, data from the original filesystem is not accounted for in the displayed capacity.
$ weka fs tier capacity
bmrb        wekalow-bmrb         0 B                       0 B             0.00           10.00
cam_archive wekalow-archive      20.39 TB                  18.80 TB        7.79           10.00
nmr_backup  wekalow-nmrbackup    519.07 GB                 518.05 GB       0.19           10.00

To list the data capacities of a specific filesystem, add the option --filesystem <filesystem name>.

$ weka fs tier capacity --filesystem cam_archive
cam_archive wekalow-archive      20.39 TB                  18.80 TB        7.79           10.00