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
Issue 6699: LTS - Prevent relocation of huge data with truncate when cluster is configured with very large max chunk size. #6700
Conversation
…cluster is configured with very large max chunk size. Signed-off-by: Sachin Joshi <sachin.joshi@emc.com>
}, chunkedSegmentStorage.getExecutor()); | ||
} | ||
return CompletableFuture.completedFuture(null); | ||
} | ||
|
||
private CompletableFuture<Void> copyBytes(ChunkHandle writeHandle, ChunkHandle readHandle, long startOffset, long length) { | ||
Preconditions.checkArgument(length <= chunkedSegmentStorage.getConfig().getMaxSizeForTruncateRelocationInbytes(), |
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.
What happens if this precondition check fails? Isn't this going to relocate the chunk? what are the consequences of that?
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.
Precondition checks as name suggests check the invariant and prevent bad execution and unwanted side effects in case input is not valid. Therefore this will throw an exception if length is not less than max allowed.
Code elsewhere (below on line 229) should mean we should never in reality invoke copyBytes with invalid arguments. But assuming that through some bizarre overflow magic we somehow ended up here with bad parameter, then this precondition will fail and prevent further damage.
SLTS in general uses "fail fast" defensive programming approach everywhere and therefore immediately stops processing to prevent further damage.
Codecov Report
@@ Coverage Diff @@
## master #6700 +/- ##
============================================
- Coverage 86.30% 86.30% -0.01%
- Complexity 15738 15743 +5
============================================
Files 1022 1022
Lines 58852 58862 +10
Branches 5960 5961 +1
============================================
+ Hits 50791 50798 +7
+ Misses 4952 4950 -2
- Partials 3109 3114 +5
Continue to review full report at Codecov.
|
…cluster is configured with very large max chunk size. (pravega#6700) Prevent relocation of huge data with truncate when cluster is configured with very large max chunk size. Signed-off-by: Sachin Joshi <sachin.joshi@emc.com>
Signed-off-by: Sachin Joshi sachin.joshi@emc.com
Change log description
Issue 6699: LTS - Prevent relocation of huge data with truncate when cluster is configured with very large max chunk size.
Purpose of the change
Fixes #6699
What the code does
Adds config value for maximum size of chunk after which it is not eligible for relocation.
How to verify it
All tests should pass