[
https://issues.apache.org/jira/browse/HDFS-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13739343#comment-13739343
]
Colin Patrick McCabe commented on HDFS-5051:
--------------------------------------------
The random jitter code was taken from the block report code. The goal is the
same-- to avoid overloading the NameNode with too many reports at the same
time. I don't see any reason to take out the jitter code here, although it
will not be as important as it was in the block report case.
As far as I can tell, genstamp and block length should not be included in the
cache report. They aren't included in the regular block report in
StorageBlockReportProto. When asking a DataNode to lock a block, the NameNode
can specify the genstamp and minimum length it wants at that time, and the
DataNode can fail the request if it doesn't have that genstamp / length. This
issue starts getting into the NN to DN communicaion (HDFS-5053). That's why I
suggested discussing it there-- although I'm happy to discuss it here as well.
> Propagate cache status information from the DataNode to the NameNode
> --------------------------------------------------------------------
>
> Key: HDFS-5051
> URL: https://issues.apache.org/jira/browse/HDFS-5051
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: datanode, namenode
> Reporter: Colin Patrick McCabe
> Assignee: Andrew Wang
> Attachments: hdfs-5051-1.patch, hdfs-5051-2.patch
>
>
> The DataNode needs to inform the NameNode of its current cache state. Let's
> wire up the RPCs and stub out the relevant methods on the DN and NN side.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
