forked from TrueCloudLab/frostfs-node
Aleksey Savchuk
d4ff44ef83
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> |
||
|---|---|---|
| .. | ||
| blobovnicza | ||
| blobstor | ||
| engine | ||
| internal | ||
| metabase | ||
| metrics | ||
| pilorama | ||
| shard | ||
| util | ||
| writecache | ||