-
Notifications
You must be signed in to change notification settings - Fork 38
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.
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
Put Storagegroup failed #2488
Comments
cthulhu-rider
added a commit
that referenced
this issue
Aug 10, 2023
Previously, `storagegroup.CollectMembers` function could return error with text `data must be 64-bytes long`. According to the message it is not clear which data is incorrect. Now context has been added to the error so that it is clear at what stage it occurs. Refs #2488. Signed-off-by: Leonard Lyubich <[email protected]>
cthulhu-rider
added a commit
that referenced
this issue
Aug 10, 2023
Previously, `storagegroup.CollectMembers` function could return error with text `data must be 64-bytes long` if any of the split members were without homomorphic checksum or with the invalid one. Including the bypass of the splitting chain, and the error occurred already after at stage `tz.Concat`. The correct format of the homomorphic checksum is required to form the group, so it is required to do an in-place check. Check each element of `IterateSplitLeaves` iterator and break traversal on any checksum problem. Refs #2488. Signed-off-by: Leonard Lyubich <[email protected]>
cthulhu-rider
added a commit
that referenced
this issue
Aug 10, 2023
Previously, `storagegroup.CollectMembers` function ignored absence of the object ID in the member's child header. This could lead to incorrect storage group formation, and also hid problem objects in the system (ID is a required field for any object). Immediately return error from `CollectMembers` if any child of any member is without ID. Refs #2488. Signed-off-by: Leonard Lyubich <[email protected]>
cthulhu-rider
added a commit
that referenced
this issue
Aug 10, 2023
Previously, `storagegroup.CollectMembers` function could return error with text `data must be 64-bytes long`. According to the message it is not clear which data is incorrect. Now context has been added to the error so that it is clear at what stage it occurs. Refs #2488. Signed-off-by: Leonard Lyubich <[email protected]>
cthulhu-rider
added a commit
that referenced
this issue
Aug 10, 2023
Previously, `storagegroup.CollectMembers` function could return error with text `data must be 64-bytes long` if any of the split members were without homomorphic checksum or with the invalid one. Including the bypass of the splitting chain, and the error occurred already after at stage `tz.Concat`. The correct format of the homomorphic checksum is required to form the group, so it is required to do an in-place check. Check each element of `IterateSplitLeaves` iterator and break traversal on any checksum problem. Refs #2488. Signed-off-by: Leonard Lyubich <[email protected]>
cthulhu-rider
added a commit
that referenced
this issue
Aug 10, 2023
Previously, `storagegroup.CollectMembers` function ignored absence of the object ID in the member's child header. This could lead to incorrect storage group formation, and also hid problem objects in the system (ID is a required field for any object). Immediately return error from `CollectMembers` if any child of any member is without ID. Refs #2488. Signed-off-by: Leonard Lyubich <[email protected]>
homomorphic checksums of group members are empty or inaccessible (rather the first)
seems like homomorphic checksums are not stamped in the split-chain elements. I'll investigate why |
cthulhu-rider
added a commit
that referenced
this issue
Aug 10, 2023
Previously, storage nodes didn't check homomorphic checksum correctness in incoming objects. When homomorphic hashing is required in the container, nodes accepted objects without homomorphic hash header. This could lead to subsequent problems with storage group creation because it expects checksums in the members' headers. Make storage nodes to check that homomorphic checksum of the new object payload is set and has correct format according to TillichZemor algo. If homomorphic hashing is disabled, the header is unchecked. Exact TZ hash value is unchecked for now due to performance issues. Refs #2488. Signed-off-by: Leonard Lyubich <[email protected]>
cthulhu-rider
added a commit
that referenced
this issue
Aug 10, 2023
Previously, storage nodes didn't calculate and set homomorphic payload checksum for the sliced objects even when it was required. This could affect Data Audit subsystem working with homomorphic hashes. Bypass hashing option from `slicingTarget` to the underlying `Slicer`. Fixes #2488. Signed-off-by: Leonard Lyubich <[email protected]>
cthulhu-rider
added a commit
that referenced
this issue
Aug 10, 2023
Previously, storage nodes didn't calculate and set homomorphic payload checksum for the sliced objects even when it was required. This could affect Data Audit subsystem working with homomorphic hashes. Bypass hashing option from `slicingTarget` to the underlying `Slicer`. Fixes #2488. Signed-off-by: Leonard Lyubich <[email protected]>
cthulhu-rider
added a commit
that referenced
this issue
Aug 10, 2023
Previously, storage nodes didn't check homomorphic checksum correctness in incoming objects. When homomorphic hashing is required in the container, nodes accepted objects without homomorphic hash header. This could lead to subsequent problems with storage group creation because it expects checksums in the members' headers. Make storage nodes to check that homomorphic checksum of the new object payload is set and has correct format according to TillichZemor algo. If homomorphic hashing is disabled, the header is unchecked. Exact TZ hash value is unchecked for now due to performance issues. Refs #2488. Signed-off-by: Leonard Lyubich <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
neofs-cli storagegroup put failed:
See in the report:
https://http.fs.neo.org/HXSaMJXk2g8C14ht8HSi7BBaiYZ1HeWh2xnWPGQCg4H6/424-1691517028/index.html#suites/69b447004f3c682f67955ec900a09cf0/e7df9c93693e0c5/
Expected Behavior
neofs-cli storagegroup put failed
Current Behavior
neofs-cli storagegroup put should not fall
Steps to Reproduce (for bugs)
Run any TestStorageGroup test
Regression
Yes
PR# that caused this regression:
#2470
Your Environment
neo-go 0.101.1
neofs-s3-authmate 0.27.1
neofs-cli d67d5d3
neofs-adm d67d5d3
AWS aws-cli/2.13.5 Python/3.11.4 Linux/5.15.0-1042-azure exe/x86_64.ubuntu.22 prompt/off
The text was updated successfully, but these errors were encountered: