TrueCloudLab/frostfs-node
18
1
Fork 27
Code Issues 90 Pull requests 3 Projects Releases 1 Activity Actions

policer: Do not drop required linking objects #854

Merged
fyrchik merged 1 commit from dstepanov-yadro/frostfs-node:fix/linking_object_replication into master 2023-12-12 11:04:04 +00:00
Conversation 2 Commits 1 Files changed 3 +32 -12
dstepanov-yadro commented 2023-12-11 11:03:37 +00:00
Member
Copy link

Closes #825

Closes #825
dstepanov-yadro reviewed 2023-12-11 11:04:19 +00:00
pkg/core/object/address.go Outdated
@ -13,0 +16,4 @@
IsLinkingObject bool
}
func (v AddressWithType) String() string {
dstepanov-yadro commented 2023-12-11 11:04:19 +00:00
Author
Member
Copy link

To use in printf-methods with %s

To use in `printf`-methods with `%s`
dstepanov-yadro requested review from storage-core-committers 2023-12-11 11:15:57 +00:00
dstepanov-yadro requested review from storage-core-developers 2023-12-11 11:15:58 +00:00
acid-ant approved these changes 2023-12-11 12:10:32 +00:00
fyrchik commented 2023-12-11 12:56:44 +00:00
Owner
Copy link

Why is it a problem? Linking object loss is tolerable, we can still build everything.
Or is it an optimization for failover cases?

Why is it a problem? Linking object loss is tolerable, we can still build everything. Or is it an optimization for failover cases?
fyrchik reviewed 2023-12-11 12:57:37 +00:00
pkg/core/object/address.go Outdated
@ -13,0 +17,4 @@
}
func (v AddressWithType) String() string {
return fmt.Sprintf("address: %s, type: %s, is linking: %s", v.Address.String(), v.Type.String(), strconv.FormatBool(v.IsLinkingObject))
fyrchik commented 2023-12-11 12:57:37 +00:00
Owner
Copy link

I think with %s we do not need to call .String() and %t is the same as FormatBool -- is your implementation intentional?

I think with `%s` we do not need to call `.String()` and `%t` is the same as `FormatBool` -- is your implementation intentional?
dstepanov-yadro commented 2023-12-11 13:57:27 +00:00
Author
Member
Copy link

Fixed

Fixed
fyrchik marked this conversation as resolved
fyrchik reviewed 2023-12-11 13:05:02 +00:00
pkg/local_object_storage/metabase/list.go Outdated
@ -217,0 +221,4 @@
var isLinkingObj bool
if objType == objectSDK.TypeRegular {
var o objectSDK.Object
if err := o.Unmarshal(v); err != nil {
fyrchik commented 2023-12-11 13:05:02 +00:00
Owner
Copy link

Doing this on every select might slow down lot's of things (policer, evacuation, basically any listing)
Don't we have some bucket from where we could take this info?

Doing this on every select might slow down lot's of things (policer, evacuation, basically any listing) Don't we have some bucket from where we could take this info?
dstepanov-yadro commented 2023-12-11 13:49:10 +00:00
Author
Member
Copy link

List used by evacuation, doctor and policier. Evacuation and doctor are mostly I/O bounded operations, so I don't think there is great impact of unmarshaling. And policier requires unmarshaling: there is no special bucket for linking objects.

Also this is metabase: objects in metabase don't contain payload, only headers etc.

`List` used by evacuation, doctor and policier. Evacuation and doctor are mostly I/O bounded operations, so I don't think there is great impact of unmarshaling. And policier requires unmarshaling: there is no special bucket for linking objects. Also this is metabase: objects in metabase don't contain payload, only headers etc.
👍 1
fyrchik marked this conversation as resolved
dstepanov-yadro commented 2023-12-11 13:37:34 +00:00
Author
Member
Copy link

Why is it a problem? Linking object loss is tolerable, we can still build everything.
Or is it an optimization for failover cases?

For example, with storage policy REP 2 CBF 2 SELECT 2 FROM * on 4 node clusted Put (or PutSingle) puts linking object on 4 node (see

Line 117 in 8d18fa1
func needAdditionalBroadcast(obj *objectSDK.Object, localOnly bool) bool {

), but in some time policier drops 2 copies (see

Line 96 in 8d18fa1
if typ == objectSDK.TypeLock || typ == objectSDK.TypeTombstone {

).

It looks like a bug. Why node saves 4 copies of linking objects, but in next second drops two of them?

> Why is it a problem? Linking object loss is tolerable, we can still build everything. > Or is it an optimization for failover cases? For example, with storage policy `REP 2 CBF 2 SELECT 2 FROM *` on 4 node clusted `Put` (or `PutSingle`) puts linking object on 4 node (see https://git.frostfs.info/TrueCloudLab/frostfs-node/src/commit/8d18fa159e085dde62336ec80f76fdfee358c412/pkg/services/object/put/common.go#L117), but in some time policier drops 2 copies (see https://git.frostfs.info/TrueCloudLab/frostfs-node/src/commit/8d18fa159e085dde62336ec80f76fdfee358c412/pkg/services/policer/check.go#L96). It looks like a bug. Why node saves 4 copies of linking objects, but in next second drops two of them?
dstepanov-yadro force-pushed fix/linking_object_replication from edddd60499 to f44d3ddc77 2023-12-11 13:51:09 +00:00 Compare
aarifullin approved these changes 2023-12-12 08:17:19 +00:00
acid-ant approved these changes 2023-12-12 10:57:34 +00:00
fyrchik merged commit 681b2c5fd4 into master 2023-12-12 11:04:04 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
aarifullin
acid-ant
Labels
Clear labels   
P0

Highest

  
P1

High

  
P2

Medium

  
P3

Low

  
badger

Badger DB related issues

  
frostfs-adm

   
frostfs-cli

   
frostfs-ir

   
frostfs-lens

   
frostfs-node

   
good first issue

Good for newcomers

  
triage
  
Infrastructure

Infrastructure, Automation, CI/CD or DevOps related stuff

  
blocked

The issue or PR is blocked by something

  
bug

Something is not working

  
config

Configuration format update or breaking change

  
discussion

Talking about something in order to reach a decision or to exchange ideas

  
documentation

Documentation related

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
go

Language features adoption

  
help wanted

Extra attention is needed

  
internal

   
invalid

Something is wrong

  
kludge

This is a kludge and we know it

  
observability

Related to metrics, tracing and logs

  
perfomance

Perfomance related

  
question

More information is needed

  
refactoring

Refactoring

  
wontfix

This won't be fixed

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
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: TrueCloudLab/frostfs-node#854
No description provided.
Delete branch "dstepanov-yadro/frostfs-node:fix/linking_object_replication"

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?