Init write-cache asynchronously #35
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
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-node#35
Loading…
Reference in a new issue
No description provided.
Delete branch "carpawell/faster-wc-init"
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?
Initialize write-cache asynchronously
?Can we do it in
defer
, just in case?Can you add a comment about why we don't need a mutex here?
@ -16,0 +39,4 @@
localWG.Wait()
select {
case <-c.stopInitCh:
I think this should be added in
c.wg
too, no?initialized
?Please, let's just make it "always async". If we ever need to configure, we can simply add
WithAsyncInitialization
option.@ -16,0 +39,4 @@
localWG.Wait()
select {
case <-c.stopInitCh:
hw, yeah, would be more reliable, added
added but depends on async flag discussion (seems like it could be even removed)
longer but dont mind
yes, that's an ugly change. problems appear when you try to (unit)test it.
WriteCache
should either be able to init in sync mode or have a feedback channel to signal about its ready state then. i decided to open PR anyway and discuss that. your thoughts?/cc @acid-ant
vote for new option for writecache
WithAsyncInitialization
and init it in background by default.Can we just use
require.Eventually
in tests?yes, but with magic numbers (how often and how long wait for that status (and how? try to
Put
object? exportStatus
func?)). do we want it?we have
Init
->Close
->Init
scenario. i could imagine that sync/async initialization could be a config value in future. also, IMO creation option should not changeInit
behaviorWe already have it in some places, I don't mind having it here.
Well, it could, but we don't need it now.
Why so?
ok, dropped
async
flag2 spaces here
@ -316,6 +317,15 @@ func newObject(t *testing.T, size int) (*object.Object, []byte) {
return obj, data
Is it enough with
-race
flag?The tests are in the
writecache
package, can we just directly check forinitialized
flag?@ -16,0 +41,4 @@
select {
case <-c.stopInitCh:
return
case <-c.closeCh:
If we use
c.wg
here, do we need to use it in 2 previous goroutines?@ -20,2 +66,4 @@
}
flushed, needRemove := c.flushStatus(addr)
if flushed {
It is enough for
setMode
to work too?I would add
yet
, not to spread panic among testers, administrators and service engineers.@ -154,3 +162,3 @@
// Finish all in-progress operations.
if err := c.SetMode(mode.ReadOnly); err != nil {
if err := c.setMode(mode.ReadOnly); err != nil {
return err
Is this line necessary?
@ -154,3 +162,3 @@
// Finish all in-progress operations.
if err := c.SetMode(mode.ReadOnly); err != nil {
if err := c.setMode(mode.ReadOnly); err != nil {
return err
you mean the empty one?
@ -20,2 +66,4 @@
}
flushed, needRemove := c.flushStatus(addr)
if flushed {
was not, fixed
@ -316,6 +317,15 @@ func newObject(t *testing.T, size int) (*object.Object, []byte) {
return obj, data
it was not but because of another reason, fixed races
@fyrchik, fixed tests with
-race
flag but now PR is a little bit more complex. Review one more time, please. Now it works but I hope it will be refactored in the future anyway.Looks like needs to be deleted.
wow, dropped
So, basically
rawWc.initialized.Load
?Why do you use a mutex with atomic
initialized
?Why have you decided to use defer here?
What happens if we fail to
Close
/Open
db? If we move to a degraded mode?@ -28,0 +42,4 @@
c.initWG.Wait()
c.stopInitCh = make(chan struct{})
defer func() {
The order is really important, can you mention that
stopInitCh
must be used only ininitWG
goroutines, to avoid races?it was not an
atomic
before and then i just changed it and forget other cases to be adopted toofixed
flashbacks from the previous implementation
looked at that one more time and it seems like an error-free and non-degraded mode switch is enough for running
initFlushMarks
one more time? check the updated version, please@ -28,0 +42,4 @@
c.initWG.Wait()
c.stopInitCh = make(chan struct{})
defer func() {
sure, added comments to that fields