Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Object expiration and lock conflict #2392

Closed
vvarg229 opened this issue Jun 19, 2023 · 0 comments
Closed

Object expiration and lock conflict #2392

vvarg229 opened this issue Jun 19, 2023 · 0 comments
Assignees
@carpawell
Labels
bug Something isn't working neofs-storage Storage node application issues U4 Nothing urgent
Milestone
v0.38.0

Comments

@vvarg229
Copy link
Contributor

Issue nspcc-dev/neofs-testcases#537 is a possible bug in the neofs-node.

Basically it's about object expiration and lock conflict which can be decided two ways:

object's expiration takes precedence over lock because it's important to satisfy expiration guarantees (including legal requirements)
lock object takes precedence over object's expiration because it's a lock and there might be a reason to lock an expired object (including legal requirements)
This can be solved with different types of locks, but we won't introduce them now. It seems that for now we better stick to the second behavior (giving slightly more options

I suggest that we discuss this issue here.
@vvarg229 vvarg229 added bug Something isn't working triage U4 Nothing urgent labels Jun 19, 2023
@roman-khimov roman-khimov added this to the v0.38.0 milestone Jun 19, 2023
@roman-khimov roman-khimov added the neofs-storage Storage node application issues label Aug 15, 2023
carpawell added a commit to carpawell/neofs-node that referenced this issue Sep 1, 2023
@carpawell
node: Accept expired locked objects
62922b2 
Allow replication of any (expired too) locked object. Information about
object locking is considered to be presented on the _container nodes_.
Refs. nspcc-dev#2392.

Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
carpawell added a commit to carpawell/neofs-node that referenced this issue Sep 1, 2023
@carpawell
node: Remove expired unlock object by the GC
889aa7b 
An object can be expired but locked (and not removed, of course). After the LOCK
object expiration, the object should be unlocked and, therefore, become
unavailable immediately not by the next GC cycle time.
Closes nspcc-dev#2392.

Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
carpawell added a commit to carpawell/neofs-node that referenced this issue Sep 1, 2023
@carpawell
node: Remove expired unlock object by the GC
6801363 
An object can be expired but locked (and not removed, of course). After the LOCK
object expiration, the object should be unlocked and, therefore, become
unavailable immediately not by the next GC cycle time.
Closes nspcc-dev#2392.

Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
carpawell added a commit to carpawell/neofs-node that referenced this issue Sep 1, 2023
@carpawell
node: Remove expired unlock object by the GC
47533fb 
An object can be expired but locked (and not removed, of course). After the LOCK
object expiration, the object should be unlocked and, therefore, become
unavailable immediately not by the next GC cycle time.
Closes nspcc-dev#2392.

Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@carpawell carpawell

Labels
bug Something isn't working neofs-storage Storage node application issues U4 Nothing urgent
Projects
None yet
Milestone
v0.38.0
Development

No branches or pull requests
3 participants
@roman-khimov @carpawell @vvarg229