The Scavenging service ensures that objects in the repository have valid metadata. When the service runs, it verifies that both the primary metadata for each object and the secondary metadata are complete, valid, and in sync with each other.
For the purpose of scavenging, HCP treats these as individual objects:
- Parts of multipart objects
- Parts of in-progress multipart uploads
- Chunks for erasure-coded objects
- Chunks for erasure-coded parts of multipart objects
To correct violations it detects, the Scavenging service tries to rebuild or repair the problem metadata:
- If the primary metadata for an object is missing, the service reconstructs it from the secondary metadata. If a user or application changed any of the object metadata between when the violation occurred and the time of its repair, those changes may be overwritten with the previous settings.
- If the primary metadata is missing a pointer to a copy of the object data, the service reconstructs that pointer.
- If the secondary metadata for an object doesn’t match any copies of the primary metadata, the object is considered irreparable, and the service moves it to the .lost+found directory, located under rest, data, or fcfs_data, as applicable,. At this point, you need to determine whether the object needs to be stored again and, if so, ensure that it happens.
You can delete an object from the .lost+found directory only when it’s not under retention.
In the default namespace, the Scavenging service detects and repairs violations in the metadata for directories only if the directory is associated with abandoned data (that is, data no longer associated with any metadata). If the service cannot recover the directory metadata, it rebuilds it from the metadata associated with the parent directory.
The Scavenging service runs according to the active service schedule.