Conversation
44855fa to
6b9f67c
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #3672 +/- ##
==========================================
- Coverage 27.32% 26.91% -0.41%
==========================================
Files 657 658 +1
Lines 41827 41735 -92
==========================================
- Hits 11429 11235 -194
- Misses 29335 29463 +128
+ Partials 1063 1037 -26 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
6b9f67c to
e7c3bae
Compare
carpawell
left a comment
There was a problem hiding this comment.
Once you drop Lock(..., locked []oid.ID) API from the engine, you must prohibit deprecated LOCK objects with payload on node's API layer. Either i do not see it, or it is not done.
| func objectLocked(tx *bbolt.Tx, currEpoch uint64, metaCursor *bbolt.Cursor, idCnr cid.ID, idObj oid.ID) bool { | ||
| if associatedWithTypedObject(currEpoch, metaCursor, idObj, object.TypeLock) { | ||
| return true | ||
| locked, lockID := associatedWithTypedObject(currEpoch, metaCursor, idObj, object.TypeLock) |
There was a problem hiding this comment.
Lock can be deleted manually
There was a problem hiding this comment.
In fact we have a test that does exactly that, that's how it was discovered initially.
There was a problem hiding this comment.
Control service.
i think it should do it hard, without any expiration/TS/GCMark status, just drop everything. not sure i understand when LOCK can be graveyarded
There was a problem hiding this comment.
I agree. But the way it currently works is via a mark. This code can be removed in future. Specifically I think that's the second part of #3476, tombstone processing will be changed significantly as well and that's where the concept of graveyard can be reconsidered.
There was a problem hiding this comment.
ok, if you are saying it will be changed
I think one of the last commits does that, but I can easily miss some code that's related to it. |
e7c3bae to
1372faf
Compare
1372faf to
20adac3
Compare
| if err != nil { | ||
| e.log.Warn("object put: pool task submitting", zap.Stringer("shard", id), zap.Error(err)) | ||
| overloaded = errors.Is(err, ants.ErrPoolOverload) | ||
| close(exitCh) |
20adac3 to
20fb2e0
Compare
|
Looks like we still have a lot of code producing old LOCKs: This needs to be fixed before merging the PR. |
| func objectLocked(tx *bbolt.Tx, currEpoch uint64, metaCursor *bbolt.Cursor, idCnr cid.ID, idObj oid.ID) bool { | ||
| if associatedWithTypedObject(currEpoch, metaCursor, idObj, object.TypeLock) { | ||
| return true | ||
| locked, lockID := associatedWithTypedObject(currEpoch, metaCursor, idObj, object.TypeLock) |
There was a problem hiding this comment.
ok, if you are saying it will be changed
| return errors.New("system object has payload") | ||
| } | ||
| if obj.AssociatedObject().IsZero() { | ||
| return errors.New("system object has zero associated object") |
There was a problem hiding this comment.
LOCK type can be specified (unexpected bugs with types; logs in debug process)
If there is an engine-level request to drop some object it should be deleted everywhere because all shards can potentially store it. Signed-off-by: Roman Khimov <roman@nspcc.ru>
Much like we have tombstones and locks broadcasted to all nodes they all
should be broadcasted to all shards to ensure proper meta handling at the shard
level. It's important for subsequent lock processing rework as well since
a lock for LINK object can be accepted by a shard not knowing about this LINK:
--- FAIL: TestStorageEngine_Put_Lock (3.11s)
--- FAIL: TestStorageEngine_Put_Lock/shards=5 (2.33s)
--- FAIL: TestStorageEngine_Put_Lock/shards=5/non-regular_target (0.67s)
put_test.go:110:
Error Trace: /home/rik/dev/neofs-node/pkg/local_object_storage/engine/put_test.go:110
Error: Expected error with "status: code = 2051 message = locking non-regular object is forbidden" in chain but got nil.
Test: TestStorageEngine_Put_Lock/shards=5/non-regular_target
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Lock can be deleted manually and in this case it's no longer active even if it's not yet physically removed. Signed-off-by: Roman Khimov <roman@nspcc.ru>
1. If any shard returns something like "object is locked" it's final, there is no point in continuing iterations. 2. Wrap and return the last error from the method, don't lose it. 3. Simplify putToShard signature, single error is sufficient here. Signed-off-by: Roman Khimov <roman@nspcc.ru>
It's no longer needed since API 2.18, we have all the data in meta index. This also removes Lock() method itself, a simple Put() of a LOCK object is sufficient now. A part of #3476. Signed-off-by: Roman Khimov <roman@nspcc.ru>
20fb2e0 to
f8eed22
Compare
CLI creates this object according to some rules known to CLI only, this should be communicated. Signed-off-by: Roman Khimov <roman@nspcc.ru>
Signed-off-by: Roman Khimov <roman@nspcc.ru>
pkg/local_object_storage/engine/lock_test.go:176:2 staticcheck S1021: should merge variable declaration with assignment on next line Not related to recent changes. Signed-off-by: Roman Khimov <roman@nspcc.ru>
f8eed22 to
7656ba6
Compare
|
Rebased, updated. It was unprepared object handling, see https://github.com/nspcc-dev/neofs-node/compare/f8eed22402d0f45bc25afb8db0a94b0f16755305..7656ba6b6cef9640a900e76bca0d04306a8f79e5. Tests still running in https://github.com/nspcc-dev/neofs-node/actions/runs/19860579457/job/56909340778 |
No description provided.