WIP: Simplify write-cache #314
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#314
Loading…
Reference in a new issue
No description provided.
Delete branch "carpawell/frostfs-node:refactor/simplify-WC"
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?
Tests are ok. All the previous scenarios works good. Some
Get
requests will be slowed down of course.bc678bb28f
to12f3458f2a
12f3458f2a
to9672484abd
@ -60,0 +65,4 @@
// Write-cache often, and for non-existing objects (persisted
// to the main storage and dropped from the WC's storage) it
// is `os.Stat` vs `os.Remove` calls after all.
res, err := c.fsTree.Get(ctx, common.GetPrm{Address: addr})
@TrueCloudLab/storage-core-committers, what do you think about it?
some thoughts:
FSTree
with some calls likeObjectSize
(os.Stat
i guess) andIterateObjectSizes
(to init metrics on every restart correctly). best idea, i think but it is anFSTree
change forwrite-cache
;metabase
with more disk operations perPut
/Delete
/Get
operation;WIP: refactor/simplify-WCto refactor/simplify-WC9672484abd
to34544502dc
@ -57,0 +43,4 @@
workersActive = true
}
stopWorkers := m.NoMetabase() && !c.mode.NoMetabase() || c.mode.ReadWrite() && !m.ReadWrite()
wow. looks too complex.
refactor/simplify-WCto Simplify write-cacheSimplify write-cacheto WIP: Simplify write-cacheClosed in favour of #377.
Pull request closed