Fix Search for EC-splitted objects #1144
Labels
No Label
P0
P1
P2
P3
badger
frostfs-adm
frostfs-cli
frostfs-ir
frostfs-lens
frostfs-node
good first issue
triage
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-node#1144
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "aarifullin/frostfs-node:feat/ec_search"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
Search
Proprely choose root OID for EC-splitted objects:
The container is created with
EC
-policy:Let's make
search
with--root
ROOT
Search with
--root
should return only user objects.If an object is small, then EC-parent's OID must be listed.
If an object is big, then the object is Split-ted, and then the parts of Split are EC-splitted. That means, then no EC-parent is listed but only the last part of
Split
(user object)Output:
Let's search with
--root
Output:
Putting small object
Output
Filter ec.parent
Output:
Then
Output (EC-chunks with this EC-parent):
ed49239407
toe7f09aea0a
e7f09aea0a
todac3cc891c
dac3cc891c
to59fa9bafd4
59fa9bafd4
toa2894350a4
@ -325,1 +344,4 @@
if ech := obj.ECHeader(); ech != nil {
err := f(tx, namedBucketItem{
name: ecParentToChunksBucketName(cnr, bucketName),
Am I right that this bucket will be removed automatically here?
Yes, it should be
Fix Search for EC-splitted objectsto WIP: Fix Search for EC-splitted objectsef3ca4dc36
to5aacb8fc86
WIP: Fix Search for EC-splitted objectsto Fix Search for EC-splitted objects@ -346,0 +374,4 @@
var attrs []objectSDK.Attribute
if obj.ECHeader() != nil {
attrs = obj.ECHeader().ParentAttributes()
objKey = objectKey(obj.ECHeader().Parent(), make([]byte, objectKeySize))
We can probably reuse the slice in the second argument, no?