HDFS-16261 Configurable grace period around deletion of invalidated blocks #3594
+440
−82
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.
Description of PR
See https://issues.apache.org/jira/browse/HDFS-16261 for more details.
The most straightforward way to introduce a grace period for replaced blocks is in the InvalidateBlocks datastructure. Work is periodically pulled from this class to be divvied up to DataNodes. This class is also reported on with JMX metrics, so one can easily see how many blocks are currently pending deletion.
I achieved the grace period by adding a new
pollNWithFilter
method toLightWeightHashSet
. InvalidateBlocks are added to the LightWeightHashSet with a calculatedreadyForDeleteAt
time. WhengetBlocksToInvalidateByLimit
is called, a filter is passed which only includes those blocks whosereadyForDeleteAt
is expired.The default grace period for blocks added to InvalidateBlocks is 0, which effectively makes all blocks immediately ready for deletion per existing behavior. When a grace period is configured, it applies only to blocks deleted through the
delHintNode
passed in RECEIVED_BLOCK messages. This minimizes the impact of this feature on blocks deleted for other reasons (i.e. if a file is deleted or through other ongoing namenode auditing).How was this patch tested?
I've added tests for the relevant pieces, and have also been running this on 2 clusters internally.
For code changes:
LICENSE
,LICENSE-binary
,NOTICE-binary
files?