Garbage collection (GC) in ECS is designed such that it runs with lower priority than I/O activity. When an object is deleted, ECS waits for garbage collection to reclaim the space allocated to that object. However, the object is marked as deleted and the deletion is reflected in the user's view of system utilization through metering and chargeback reports.
Data and system metadata are written in chunks on ECS. An ECS chunk is a 128MB logical container of contiguous space. Each chunk can have data from different objects. ECS uses indexing to track all the parts of an object that may be spread across different chunks and nodes. Chunks are written in an append-only pattern. The append-only behavior means that an application's request to modify or update an existing object will not modify or delete the previously written data within a chunk. But rather, the new modifications or updates will be written in a new chunk.
Writing chunks in an append-only manner means that data is added or updated by first keeping the original written data in place and second by creating net new chunk segments, which may or may not be included in the chunk container of the original object. The benefit of append-only data modification is an active/active data access model, which is not hindered by file-locking issues of traditional file systems. This being the case, as objects are updated or deleted, the data in chunks that is no longer referenced or needed is referred to as Garbage.
For optimum performance, file size must not exceed 128 MB to provide more consistent data transfers and even out the workload to the ECS. Larger files add additional CPU load which reduces performance.
ECS uses two garbage collection methods to reclaim space from discarded full chunks, or chunks containing a mixture of deleted and nondeleted object fragments that are no longer referenced. These methods are:
- Normal GC
- When an entire chunk is garbage, reclaim the space.
- Partial GC by Merge
- When a chunk is 0.66 garbage, reclaim the chunk by merging the valid parts with other partially filled chunks in a new chunk, then reclaim the space.
Note: While designing a solution, take care such that the total ingest rate to the ECS cluster does not exceed the Garbage collection rate for the cluster.
By default, the garbage collection process is purposely configured to run slowly in a conservative effort to protect against data loss. Our testing shows that this process can be safely tuned to reclaim space more quickly, while remaining a safe operation. Our suggested garbage collection parameters are:
- Decrease the time interval for the frequency of verification scanner
- Increase the scanner throttle for number of objects
- Increase the scan tasks expiration times
- Increase the maximum number of pending partial GC tasks
Contact Dell ECS technical support for more information about tuning these parameters.
Note: Bucket level retention on ECS should not be used. ISS handles the retention policy so bucket level retention is not recommended.