Speed up writecache initialization#2068
Merged
fyrchik merged 5 commits intonspcc-dev:masterfrom Dec 2, 2022
Merged
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2068 +/- ##
==========================================
+ Coverage 30.61% 30.88% +0.26%
==========================================
Files 380 381 +1
Lines 28130 28179 +49
==========================================
+ Hits 8613 8702 +89
+ Misses 18778 18738 -40
Partials 739 739
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
acid-ant
approved these changes
Nov 17, 2022
carpawell
reviewed
Nov 17, 2022
| func (c *cache) isFlushed(addr oid.Address) bool { | ||
| var prm meta.StorageIDPrm | ||
| prm.SetAddress(addr) | ||
| func (c *cache) flushStatus(addr oid.Address) (bool, bool) { |
Member
There was a problem hiding this comment.
add docs about duplicated returned types?
Signed-off-by: Evgenii Stratonikov <evgeniy@morphbits.ru>
Signed-off-by: Evgenii Stratonikov <evgeniy@morphbits.ru>
Signed-off-by: Evgenii Stratonikov <evgeniy@morphbits.ru>
Signed-off-by: Evgenii Stratonikov <evgeniy@morphbits.ru>
Signed-off-by: Evgenii Stratonikov <evgeniy@morphbits.ru>
|
I have recieved a notification of a new pull request. I am starting the build of images and binaries for further testing. Build number is 3722 |
|
I am running integration tests |
|
Test run is finished. Please download the tarball from link. Untar and use |
acid-ant
approved these changes
Nov 29, 2022
carpawell
approved these changes
Nov 30, 2022
roman-khimov
added a commit
that referenced
this pull request
Jun 24, 2025
The problem is that it can take a significant amount of time to perform while the value is questionable. It was initially added in 8717820 (#1462) when write cache had completely different structure and function. 733a792 tried to optimize it in #2068, but most of the code was subsequently deleted and as write cache is no longer a read cache this lead to the remaining code doing only the following: * checking objects against the metabase * checking objects against the underlying long-term storage If the first one is ever triggered (we detect non-existent object) this just means WC is out of sync with metabase which can happen for a number of other reasons. Lower level blobstor can also get out of sync with metabase in some cases, so it's not like this is something unique. If we're to drop this check we'd just flush some dead object, but then GC should still be able to remove it if it's deleted normally. If it's some other type of race --- like WC accepted an object and metabase not yet then we shouldn't delete it at all for safety reasons. Then if some valid object was previously flushed already we'll retry flushing it again and it's not a problem, EEXIST is not an error (but #2563), so we'd waste some time, but it's not very likely we're going to since this case is rare. So it should be safe to drop this useless code. Signed-off-by: Roman Khimov <roman@nspcc.ru>
roman-khimov
added a commit
that referenced
this pull request
Jun 24, 2025
The problem is that it can take a significant amount of time to perform while the value is questionable. It was initially added in 8717820 (#1462) when write cache had completely different structure and function. 733a792 tried to optimize it in #2068, but most of the code was subsequently deleted and as write cache is no longer a read cache this lead to the remaining code doing only the following: * checking objects against the metabase * checking objects against the underlying long-term storage If the first one is ever triggered (we detect non-existent object) this just means WC is out of sync with metabase which can happen for a number of other reasons. Lower level blobstor can also get out of sync with metabase in some cases, so it's not like this is something unique. If we're to drop this check we'd just flush some dead object, but then GC should still be able to remove it if it's deleted normally. If it's some other type of race --- like WC accepted an object and metabase not yet then we shouldn't delete it at all for safety reasons. Then if some valid object was previously flushed already we'll retry flushing it again and it's not a problem, EEXIST is not an error (but #2563), so we'd waste some time, but it's not very likely we're going to since this case is rare. So it should be safe to drop this useless code. Signed-off-by: Roman Khimov <roman@nspcc.ru>
roman-khimov
added a commit
that referenced
this pull request
Jun 24, 2025
The problem is that it can take a significant amount of time to perform while the value is questionable. It was initially added in 8717820 (#1462) when write cache had completely different structure and function. 733a792 tried to optimize it in #2068, but most of the code was subsequently deleted and as write cache is no longer a read cache this lead to the remaining code doing only the following: * checking objects against the metabase * checking objects against the underlying long-term storage If the first one is ever triggered (we detect non-existent object) this just means WC is out of sync with metabase which can happen for a number of other reasons. Lower level blobstor can also get out of sync with metabase in some cases, so it's not like this is something unique. If we're to drop this check we'd just flush some dead object, but then GC should still be able to remove it if it's deleted normally. If it's some other type of race --- like WC accepted an object and metabase not yet then we shouldn't delete it at all for safety reasons. Then if some valid object was previously flushed already we'll retry flushing it again and it's not a problem, EEXIST is not an error (but #2563), so we'd waste some time, but it's not very likely we're going to since this case is rare. So it should be safe to drop this useless code. Signed-off-by: Roman Khimov <roman@nspcc.ru>
roman-khimov
added a commit
that referenced
this pull request
Jun 24, 2025
The problem is that it can take a significant amount of time to perform while the value is questionable. It was initially added in 8717820 (#1462) when write cache had completely different structure and function. 733a792 tried to optimize it in #2068, but most of the code was subsequently deleted and as write cache is no longer a read cache this lead to the remaining code doing only the following: * checking objects against the metabase * checking objects against the underlying long-term storage If the first one is ever triggered (we detect non-existent object) this just means WC is out of sync with metabase which can happen for a number of other reasons. Lower level blobstor can also get out of sync with metabase in some cases, so it's not like this is something unique. If we're to drop this check we'd just flush some dead object, but then GC should still be able to remove it if it's deleted normally. If it's some other type of race --- like WC accepted an object and metabase not yet then we shouldn't delete it at all for safety reasons. Then if some valid object was previously flushed already we'll retry flushing it again and it's not a problem, EEXIST is not an error (but #2563), so we'd waste some time, but it's not very likely we're going to since this case is rare. So it should be safe to drop this useless code. Signed-off-by: Roman Khimov <roman@nspcc.ru>
roman-khimov
added a commit
that referenced
this pull request
Jun 25, 2025
The problem is that it can take a significant amount of time to perform while the value is questionable. It was initially added in 8717820 (#1462) when write cache had completely different structure and function. 733a792 tried to optimize it in #2068, but most of the code was subsequently deleted and as write cache is no longer a read cache this lead to the remaining code doing only the following: * checking objects against the metabase * checking objects against the underlying long-term storage If the first one is ever triggered (we detect non-existent object) this just means WC is out of sync with metabase which can happen for a number of other reasons. Lower level blobstor can also get out of sync with metabase in some cases, so it's not like this is something unique. If we're to drop this check we'd just flush some dead object, but then GC should still be able to remove it if it's deleted normally. If it's some other type of race --- like WC accepted an object and metabase not yet then we shouldn't delete it at all for safety reasons. Then if some valid object was previously flushed already we'll retry flushing it again and it's not a problem, EEXIST is not an error (but #2563), so we'd waste some time, but it's not very likely we're going to since this case is rare. So it should be safe to drop this useless code. Signed-off-by: Roman Khimov <roman@nspcc.ru>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.