Aleksey Savchuk
d4ff44ef83
All checks were successful
DCO action / DCO (pull_request) Successful in 17m11s
Pre-commit hooks / Pre-commit (pull_request) Successful in 18m42s
Vulncheck / Vulncheck (pull_request) Successful in 19m49s
Tests and linters / Run gofumpt (pull_request) Successful in 20m25s
Tests and linters / Tests (pull_request) Successful in 20m34s
Build / Build Components (pull_request) Successful in 21m8s
Tests and linters / Lint (pull_request) Successful in 21m11s
Tests and linters / Tests with -race (pull_request) Successful in 21m22s
Tests and linters / Staticcheck (pull_request) Successful in 21m31s
Tests and linters / gopls check (pull_request) Successful in 22m18s
Suppose there's a complex object stored with EC. It's divided into parts, and these parts are further divided into chunks, except for the linking object. The chunks and linking object are stored in the metabase. An expiration epoch of the original object should be stored in the expired objects index. In the described scenario, there's no way to determine the expiration epoch of the object from its chunks because a chunk's parent is a part of the original object, not the original object itself. However, the epoch can be determined from the linking object. Previously, whether the epoch was stored or not depended on the order in which the chunks and linking object were written. Now it's fixed. The absense of the expiration epoch prevented the GC from deleting this object upon its expiration. Signed-off-by: Aleksey Savchuk <a.savchuk@yadro.com> |
||
|---|---|---|
| .. | ||
| ape | ||
| core | ||
| innerring | ||
| local_object_storage | ||
| morph | ||
| network | ||
| services | ||
| tracing | ||
| util | ||