Fix Get EC object from non container node #1253
No reviewers
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#1253
Loading…
Reference in a new issue
No description provided.
Delete branch "dstepanov-yadro/frostfs-node:fix/ec_get_non_container_node"
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?
How it was: first, we collected information about the chunks of the EC object, taking into account the TTL, then we requested the chunks. This led to the fact that there was not enough TTL to collect information about the chunks: client -> node1 (non container, ttl=2) -> node2 (container, ttl=1), node2 can't get other chunks because of ttl=1.
How it became: first we get information that the object is an EU object, and then we collect information about the chunks and the chunks themselves in separate requests from the container node.
19db4bd93d
to795490b790
795490b790
toead691417b
@ -32,2 +36,3 @@
}
p := getsvc.HeadPrm{}
p.SetCommonParameters(exec.commonParameters())
p.SetCommonParameters(&commonParameters)
commonParameters
may be changed during Head request (ForgetTokens
,WithLocalOnly
), so need a copy. Founded with autotests.Previously it was possible to pass
nil
, now we pass a pointer to the empty struct.This is a change in behaviour, can anything bad happen?
Previously it was possible to pass
nil
, now we pass a pointer to the empty struct.This is a change in behaviour, can anything bad happen?
Fixed
@ -36,2 +37,4 @@
r.log.Debug(logs.GetTryingToAssembleTheECObject)
// initialize epoch number
ok := r.initEpoch()
Logging and status change - inside
r.initEpoch()
method.ead691417b
to84d58795ce
84d58795ce
to47de122454
47de122454
toacc6c917b1
acc6c917b1
to6917d9b285
@ -104,2 +142,2 @@
parts := a.retrieveParts(ctx, false)
c, err := a.getConstructor()
objID := a.addr.Object()
trav, cnr, err := a.traverserGenerator.GenerateTraverser(a.addr.Container(), &objID, a.epoch)
This part seems to be common for all
reconstruct*()
helpers. If we move it one level above, will it make the code cleaner?Done
@ -156,0 +200,4 @@
chunksGuard.Lock()
defer chunksGuard.Unlock()
for _, ch := range nodeChunks {
chunks[string(ch.ID.GetValue())] = ch
We can override the old value here, does it matter?
We can override the old value here, does it matter?
We can override the old value here, does it matter?
We can override the old value here, does it matter?
We can override the old value here, does it matter?
We can override the old value here, does it matter?
We can override the old value here, does it matter?
We can override the old value here, does it matter?
We can override the old value here, does it matter?
ch.ID
is objectID. In certain situations, you can get the same chunk from different nodes.@ -159,1 +233,4 @@
}
func (a *assemblerec) processECNodesRequests(ctx context.Context, nodes []placement.Node, dataCount, parityCount int) ([]*objectSDK.Object, error) {
foundedChunks := make(map[uint32]*objectSDK.Object)
s/founded/found
, founded is what happened with Saint-Petersburg in 1703 :)Fixed
@ -474,6 +478,7 @@ func testNodeMatrix(t testing.TB, dim []int) ([][]netmap.NodeInfo, [][]string) {
var ni netmap.NodeInfo
ni.SetNetworkEndpoints(a)
ni.SetPublicKey([]byte(a))
Why is it important?
Why is it important?
Get
service uses node's public key as map key for EC chunks. Without this change all chunks belong to the same node without public key in unit tests, so unit test fails.6917d9b285
to0d76caf8df
@ -160,0 +257,4 @@
return ctx.Err()
default:
}
chunks := a.tryGetChunkListFromNode(ctx, info)
Just for my curiosity:
We get the list of chunks available on the observing
node
- could these sets ofchunks
be intersected by some reason?It still works as you're using
foundChunks
map but can be some chunks is gotten bytryGetChunkFromRemoteStorage
a few times?Yes, in case of remove shard/return shard scenario. But it looks like rare case.
0d76caf8df
toe83d39e33f
@ -156,0 +203,4 @@
dataCount := policy.ECDataCount(cnr.Value.PlacementPolicy())
parityCount := policy.ECParityCount(cnr.Value.PlacementPolicy())
remoteNodes := make([]placement.Node, 0)
var remoteNodes []placement.Node
?