Fix Search for EC-splitted objects #1144
Labels
No labels
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 a new issue
No description provided.
Delete branch "aarifullin/frostfs-node:feat/ec_search"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. 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?