[
https://issues.apache.org/jira/browse/HDFS-8674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14975701#comment-14975701
]
Hadoop QA commented on HDFS-8674:
---------------------------------
\\
\\
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | patch | 0m 0s | The patch command could not apply
the patch during dryrun. |
\\
\\
|| Subsystem || Report/Notes ||
| Patch URL |
http://issues.apache.org/jira/secure/attachment/12742164/HDFS-8674.patch |
| Optional Tests | javadoc javac unit findbugs checkstyle |
| git revision | trunk / 96677be |
| Console output |
https://builds.apache.org/job/PreCommit-HDFS-Build/13211/console |
This message was automatically generated.
> Improve performance of postponed block scans
> --------------------------------------------
>
> Key: HDFS-8674
> URL: https://issues.apache.org/jira/browse/HDFS-8674
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: HDFS
> Affects Versions: 2.6.0
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Priority: Critical
> Attachments: HDFS-8674.patch
>
>
> When a standby goes active, it marks all nodes as "stale" which will cause
> block invalidations for over-replicated blocks to be queued until full block
> reports are received from the nodes with the block. The replication monitor
> scans the queue with O(N) runtime. It picks a random offset and iterates
> through the set to randomize blocks scanned.
> The result is devastating when a cluster loses multiple nodes during a
> rolling upgrade. Re-replication occurs, the nodes come back, the excess block
> invalidations are postponed. Rescanning just 2k blocks out of millions of
> postponed blocks may take multiple seconds. During the scan, the write lock
> is held which stalls all other processing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
