This function was very obfuscated. I hope the newer version is more
clear, but IMHO it keeps being bad because:
- Its name is confusing because it checks both the graveyard and the
garbage.
- It has no interface. We use that function in several metabase methods,
it just returns some 'magic' uint8 numbers and has no doc comment, I
mean it's ridiculous.
- It checks out for 'the node being in incorrect state' for some reason
but that result isn't used further. I kept a comment about that but it
has no logic for me.
Signed-off-by: Aleksey Savchuk <a.savchuk@yadro.com>
Target container ID is taken from tombstone: cmd/frostfs-node/object.go:507
Also object of type `TOMBSTONE` contains objectID, so tombstone and
tombstoned object must have the same containerID.
Signed-off-by: Dmitrii Stepanov <d.stepanov@yadro.com>
For EC chunks need to return EC parent object ID as
EC chunks don't have own attributes but inherit parent's.
Signed-off-by: Dmitrii Stepanov <d.stepanov@yadro.com>
Do not fail on same latest version to run compact on upgraded metabase.
Use NoSync on compact.
Log every batch on bucket delete stage.
Signed-off-by: Dmitrii Stepanov <d.stepanov@yadro.com>
Since Go 1.22 a "for" statement with a "range" clause is able
to iterate through integer values from zero to an upper limit.
gopatch script:
@@
var i, e expression
@@
-for i := 0; i <= e - 1; i++ {
+for i := range e {
...
}
@@
var i, e expression
@@
-for i := 0; i <= e; i++ {
+for i := range e + 1 {
...
}
@@
var i, e expression
@@
-for i := 0; i < e; i++ {
+for i := range e {
...
}
Signed-off-by: Ekaterina Lebedeva <ekaterina.lebedeva@yadro.com>
When node put chunk into EC container, `policer` may remove it as redundant.
This chunk marked as removed. When parent object removed and `gc` start iterating over chunk,
node count removing chunk twice.
Signed-off-by: Anton Nikiforov <an.nikiforov@yadro.com>
EC parent and split gc marks should be deleted after last EC chunk delete.
Also should delete split info for EC parent and split parent.
Signed-off-by: Dmitrii Stepanov <d.stepanov@yadro.com>
It is required to save split parent ID too, not only split ID.
Otherwise inhume operation works incorrect: shard with last part may be skipped
and parent object will be available.
Signed-off-by: Dmitrii Stepanov <d.stepanov@yadro.com>
For REP updating split info is handled explicitly by a high-level PUT logic.
For EC it is trickier, because the address of an object we put is only
distantly related to a split info.
Signed-off-by: Evgenii Stratonikov <e.stratonikov@yadro.com>
* If EC-parent is a part of Split itself, then save to root bucket
its parent;
* If EC-parent is not a part of Split itself, then save to root bucket
OID of this EC-parent.
Signed-off-by: Airat Arifullin <a.arifullin@yadro.com>
* `GetECHeader` is not correct way to determine if an object's got
EC-header: `ECHeader` must be used for that.
Signed-off-by: Airat Arifullin <a.arifullin@yadro.com>
metabase.Open() now reports metabase mode metric. shard.UpdateID()
needs to read shard ID from metabase => needs to open metabase.
It caused reporting 'shard undefined' metrics. To avoid reporting
wrong metrics metabase.GetShardID() was added which also opens
metabase and does not report metrics.
Signed-off-by: Ekaterina Lebedeva <ekaterina.lebedeva@yadro.com>
It used to always show CLOSED regardless of actual mode.
Now metric represents actual metabase mode of operations.
Signed-off-by: Ekaterina Lebedeva <ekaterina.lebedeva@yadro.com>
