summaryrefslogtreecommitdiff
path: root/src/buildtool/storage/garbage_collector.hpp
AgeCommit message (Collapse)Author
2025-06-12GarbageCollector: Support removal of all generations at onceMaksim Denisov
...that ignores compactification.
2024-11-14storage: Implement IWYU suggestionsPaul Cristian Sarbu
2024-07-05Call uplinking via UplinkerMaksim Denisov
... instead of static calls to GarbageCollector
2024-07-05Pass StorageConfig to GarbageCollectionMaksim Denisov
2024-07-05Pass StorageConfig to GarbageCollector::SharedLockMaksim Denisov
2024-04-17Compactification: Split large entries.Maksim Denisov
During garbage collection split and remove from the storage every entry that is larger than a threshold.
2024-04-17Compactification: Remove spliced entries.Maksim Denisov
During garbage collection remove from the storage every entry that has the large entry.
2024-04-02LargeBlobs: Uplink large objects.Maksim Denisov
* Uplink parts of the large entry before entry itself; * Uplink large entries in LargeObjectCAS::GetEntryPath to not split things two times; * Promote spliced tree during uplinking of a large tree entry to properly promote parts of the tree; * Uplink large entries in LocalUplink{Blob, Tree} to support proper uplinking in Action Cache and Target Cache; Tested: * Uplink large blobs and trees; * Uplink a large object that depends on other large objects.
2024-03-19serve target: Fix sharding inconsistenciesPaul Cristian Sarbu
When running in single node, serve endpoint should not even consider sharding. Additionally, garbage collection uplinking should also take the shard into account. For this purpose, a TargetCache instance now remembers if it was explicitly sharded and passed that information to the GarbageCollector for uplinking.
2024-03-19garbage_collector: Fix small doc typosPaul Cristian Sarbu
2024-03-11garbage collection: remove ephemeral dataKlaus Aehlig
... and make rotation of generations optional, as with the removal of ephemeral data there is now a useful collection even without rotating generations.
2023-03-13Storage: Reworked storage and garbage collectionOliver Reiche
The improved GC implementation uses refactored storage classes instead of directly accessing "unknown" file paths. The required storage class refactoring is quite substantial and outlined in the following paragraphs. The module `buildtool/file_system` was extended by: - `ObjectCAS`: a plain CAS implementation for reading/writing blobs and computing digests for a given `ObjectType`. Depending on that type, files written to the file system may have different properties (e.g., the x-bit set) or the digest may be computed differently (e.g., tree digests in non-compatible mode). A new module `buildtool/storage` was introduced containing: - `LocalCAS`: provides a common interface for the "logical CAS", which internally combines three `ObjectCAS`s, one for each `ObjectType` (file, executable, tree). - `LocalAC`: implements the action cache, which needs the `LocalCAS` for storing cache values. - `TargetCache`: implements the high-level target cache, which also needs the `LocalCAS` for storing cache values. - `LocalStorage`: combines the storage classes `LocalCAS`, `LocalAC`, and `TargetCache`. Those are initialized with settings from `StorageConfig`, such as the build root base path or number of generations for the garbage collector. `LocalStorage` is templated with a Boolean parameter `kDoGlobalUplink`, which indicates that, on every read/write access, the garbage collector should be used for uplinking across all generations (global). - `GarbageCollector`: responsible for garbage collection and the global uplinking across all generations. To do so, it employs instances of `LocalStorage` with `kDoGlobalUplink` set to false, in order to avoid endless recursion. The actual (local) uplinking within two single generations is performed by the corresponding storage class (e.g., `TargetCache` implements uplinking of target cache entries between two target cache generations etc.). Thereby, the actual knowledge how data should be uplinked is implemented by the instance that is responsible for creating the data in the first place.