-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix store: handle invalid cache block dir #1505
fix store: handle invalid cache block dir #1505
Conversation
CI failing in master, will rebase once fixed |
cff24a3
to
0b60b5f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi there, thanks for the contribution! The code itself looks okay and I get the idea but I have taken a look at your original ticket. As I understand it, all of the data looks okay in the remote object storage but you have empty directories in your local disk. However, how could this be if we run SyncBlocks()
before? It seems like the correct place to fix here is this: https://github.com/thanos-io/thanos/blob/master/pkg/store/bucket.go#L1191 - we should probably add this check there. @FUSAKLA WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for lag @FUSAKLA
I think I fully agree with @GiedriusS
It looks like our loadMeta
is just broken as it assumes that if dir is present then meta.json is present as well. We should rather check for meta.json directly.
This thing is happening because if you restart store in wrong moment (when it syncs blocks meta.json), the directory can be created by meta.json not downloaded. Thanks for fixing this bug - it's quite edge case bug, but serious as we skip data!
Thanks!
Hi, yes @GiedriusS that totally makes sense. Thanks for the suggestion will refactor right away. Just to add to the rarity. It's happening quite often in our production since upgrading to the 0.7.0 which is weird, but this should solve it. |
Signed-off-by: Martin Chodur <m.chodur@seznam.cz>
0b60b5f
to
c58038a
Compare
@GiedriusS Should be moved as you suggested, PTAL if that is what you meant. |
pkg/block/block.go
Outdated
@@ -153,3 +153,10 @@ func IsBlockDir(path string) (id ulid.ULID, ok bool) { | |||
id, err := ulid.Parse(filepath.Base(path)) | |||
return id, err == nil | |||
} | |||
|
|||
func HasMetaFile(blockPath string) bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am against this shallow function - such helper is not needed - the oneliner below is exactly enough for this.
In the same way, there is no Max(a, b)
function is go standard library. You just do this one if
on your own (:
What do you think, can we just inline this logic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could do what @bwplotka suggests, it might be neater. 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I eventually simplified it to checking directly for the meta file which should also provide the check for the directory existence right away. The creation of dir is agnostic to it's existence and new downloaded files should overwrite those existing in the block dir.
Thanks @bwplotka for pointing this out I just saw the IsBlockDir
func so I somehow followed the pattern.
PTAL if this is ok with you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks for this fix! The logic seems correct to me now. Even if other errors will occur while doing a stat(2)
on the meta file, it's not a problem since it will be caught later by the reading routine.
Signed-off-by: Martin Chodur <m.chodur@seznam.cz>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, good choice with checking file directly!
LGTM, thanks!
* fix store: handle invalid cache block dir Signed-off-by: Martin Chodur <m.chodur@seznam.cz> * CR: simplify empty store cache block validation logic Signed-off-by: Martin Chodur <m.chodur@seznam.cz>
fixes #1504
Changes
meta.json
on startup