engine: Allow to remove redundant object copies #191
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
5 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-node#191
Loading…
Reference in a new issue
No description provided.
Delete branch "fyrchik/frostfs-node:shard-reinsertion"
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?
RemoveDuplicates() accepts a single shard and removes all copies stored on
other shards. The naming comes from the fact that it could support
objects removal from the shard which are lower in the HRW vector.
What to test:
--concurrency
flag (1 vs 1000) should have noticeable effect on the command execution time.object get --ttl 1
.Blocked until further discussion.
7d2e088e68
to945367bb94
WIP: engine: Allow to remove redundant object copiesto engine: Allow to remove redundant object copies@ -0,0 +24,4 @@
pk := key.Get(cmd)
req := &control.DoctorRequest{Body: new(control.DoctorRequest_Body)}
req.Body.Concurrency, _ = cmd.Flags().GetUint32(concurrencyFlag)
[Optinal]
Using
GetUint32
,GetBool
is fine, but if new flags are added todoctor
command, then it will be not obvious thatconcurrencyFlag
is uint32 andsomeNewFlag
issomeType
I think that is fine to use global variables to initialize flags
We had a problem with this, because in some cases "the same" flag should have different descriptions/defaults in different commands. With many global variables this had become a mess.
Anyway, I suggest discussing it separately and implementing in all CLI commands atomically, after reaching consensus.
@ -0,0 +120,4 @@
}
var deletePrm shard.DeletePrm
deletePrm.SetAddresses(addr)
Wouldn't be helpful to log shards that have had the same object?
Given the amount of logs we have, no. The only use-case I see is for testing.
Deletion operation is already logged, may be we can add a single log entry when we start processing a shard.
@ -0,0 +61,4 @@
var cursor *meta.Cursor
for {
var listPrm shard.ListWithCursorPrm
listPrm.WithCount(uint32(prm.Concurrency))
Why count =
prm.Concurrency
?Even named constant is magic in this case and it seems logic to depend on the number of workers which process listed object.
What else could we use here?
If
prm.Concurrency = 1
then there will be too many bbolt requests, it seems to me.If I knew for sure... But if you don't have any other ideas, I agree with this approach.
@ -0,0 +81,4 @@
}
})
for i := 0; i < defaultRemoveDuplicatesConcurrency; i++ {
Not
defaultRemoveDuplicatesConcurrency
, butprm.Concurrency
?Fixed.
@ -0,0 +109,4 @@
var existsPrm shard.ExistsPrm
existsPrm.SetAddress(addr)
res, err := shards[i].Exists(existsPrm)
Do we need to exclude shard, where object was found? If object is placed on single shard, will it be deleted?
It won't and I guess that why
found
flag is needed. The deletion of the first object is ignored by the flag. If object is met again, then_, err = shards[i].Delete(deletePrm)
Here is the logic:
@ -194,0 +198,4 @@
wResp := &doctorResponseWrapper{new(DoctorResponse)}
wReq := &requestWrapper{m: req}
err := client.SendUnary(cli, common.CallMethodInfoUnary(serviceName, rpcDoctor), wReq, wResp, opts...)
There is no timeout for RPC call?
It is hidden inside the client. https://git.frostfs.info/TrueCloudLab/frostfs-node/src/branch/master/cmd/frostfs-cli/internal/client/sdk.go#L53 (yes, we could improve this)
@ -0,0 +9,4 @@
"google.golang.org/grpc/status"
)
func (s *Server) Doctor(ctx context.Context, req *control.DoctorRequest) (*control.DoctorResponse, error) {
Will
context
be canceled if the command execution is interrupted?Haven't tested this, but I would expect this from the gRPC.
945367bb94
to4235c6425f
4235c6425f
tod11b15e5da
Added some logs to aid testing (not too much), please look.
d11b15e5da
to988c55c6b9