Use `zap.Error` instead of `zap.String` for logging errors: change all expressions like
`zap.String("error", err.Error())` or `zap.String("err", err.Error())` to `zap.Error(err)`.
Leave similar expressions with other messages unchanged, for example,
`zap.String("last_error", lastErr.Error())` or `zap.String("reason", ctx.Err().Error())`.
This change was made by applying the following patch:
```diff
@@
var err expression
@@
-zap.String("error", err.Error())
+zap.Error(err)
@@
var err expression
@@
-zap.String("err", err.Error())
+zap.Error(err)
```
Signed-off-by: Aleksey Savchuk <a.savchuk@yadro.com>
- Fix misplaced `(*DB).Close` (broken after 47dcfa20f3)
- Use `errors.Is` for error checking (broken after fcdbf5e509)
Signed-off-by: Aleksey Savchuk <a.savchuk@yadro.com>
Since we have errors defined on the shard-level, it looks strage that we
check an error againt the shard-level error `ErrLockObjectRemoval`, but
then return the metabase-level error. Let's return the same shard-level
error instead.
Since we have errors defined on the shard-level
Signed-off-by: Aleksey Savchuk <a.savchuk@yadro.com>
Currently, it's allowed to inhume or lock an expired object.
Consider the following scenario:
1) An user inhumes or locks an object
2) The object expires
3) GC hasn't yet deleted the object
4) The node loses the associated tombstone or lock
5) Another node replicates tombstone or lock to the first node
In this case, the second node succeeds, which is the desired behavior.
Signed-off-by: Aleksey Savchuk <a.savchuk@yadro.com>
DropGraves() is only used to drop gravemarks after a tombstone
removal. Thus, it makes sense to do Inhume() and DropGraves() in one
transaction. It has less overhead and no unexpected problems in case
of sudden power failure.
Signed-off-by: Evgenii Stratonikov <e.stratonikov@yadro.com>
- Remove `testNewShard` and `setInitializedShards` because they
violated the default engine workflow. The correct workflow is:
first use `New()`, followed by `Open()`, and then `Init()`. As a
result, adding new logic to `(*StorageEngine).Init` caused several
tests to fail with a panic when attempting to access uninitialized
resources. Now, all engines created with the test utils must be
initialized manually. The new helper method `prepare` can be used
for that purpose.
- Additionally, `setInitializedShards` hardcoded the shard worker
pool size, which prevented it from being configured in tests and
benchmarks. This has been fixed as well.
- Ensure engine initialization is done wherever it was missing.
- Refactor `setShardsNumOpts`, `setShardsNumAdditionalOpts`, and
`setShardsNum`. Make them all depend on `setShardsNumOpts`.
Signed-off-by: Aleksey Savchuk <a.savchuk@yadro.com>
Move `BenchmarkExists` from `engine_test.go` to `exists_test.go`
for better organization and clarity.
Signed-off-by: Aleksey Savchuk <a.savchuk@yadro.com>
The slice returned from bucket.Get() is only valid during the tx
lifetime. Cloning it is not necessary everywhere, but better safe than
sorry.
Signed-off-by: Evgenii Stratonikov <e.stratonikov@yadro.com>
Concurrent Apply can lead to child node applies before parent, so
undo/redo operations will perform. This leads to performance degradation
in case of tree with many sublevels.
Signed-off-by: Dmitrii Stepanov <d.stepanov@yadro.com>
* Update version within go.mod;
* Fix deprecated frostfs-api-go/v2 package and use frostfs-sdk-go/api
instead.
Signed-off-by: Airat Arifullin <a.arifullin@yadro.com>
`slices.SortFunc` doesn't use reflection and is a bit faster.
I have done some micro-benchmarks for `[]NodeInfo`:
```
$ benchstat -col "/func" out
goos: linux
goarch: amd64
pkg: git.frostfs.info/TrueCloudLab/frostfs-node/pkg/local_object_storage/pilorama
cpu: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
│ sort.Slice │ slices.SortFunc │
│ sec/op │ sec/op vs base │
Sort-8 2.130µ ± 2% 1.253µ ± 2% -41.20% (p=0.000 n=10)
```
Haven't included them, though, as they I don't see them being used a
lot.
Signed-off-by: Evgenii Stratonikov <e.stratonikov@yadro.com>
