[
https://issues.apache.org/jira/browse/HDFS-15764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17299050#comment-17299050
]
Ayush Saxena commented on HDFS-15764:
-------------------------------------
Sorry for coming in late, but I agree with [~hexiaoqiao] we shouldn't land up
in such a state where there can be a flood of calls to namenode, due to some
volume failure or stuff.
But I don't deny the fact that if we think of normal scenarios, where one or
two replicas got corrupt this feature will be good in that case.
Does having an upper-bound on the number of replicas being immediately reported
on each datanode, makes sense? We may reset that count to 0 again may be either
every configured time-period or post every BR?
> Notify Namenode missing or new block on disk as soon as possible
> ----------------------------------------------------------------
>
> Key: HDFS-15764
> URL: https://issues.apache.org/jira/browse/HDFS-15764
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: datanode
> Reporter: Yang Yun
> Assignee: Yang Yun
> Priority: Minor
> Attachments: HDFS-15764.001.patch, HDFS-15764.002.patch,
> HDFS-15764.003.patch
>
>
> When a bock file is deleted on disk or copied back to the disk, the
> DirectoryScanner can find the change, but the namenode know the change only
> untill the next full report. And in big cluster the period of full report is
> set to long time invterval.
> Call notifyNamenodeDeletedBlock if block files are deleted and call
> notifyNamenodeReceivedBlock if the block files is found agian. So the
> Incremental block report can send the change to namenode in next heartbeat.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
