You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-issues@hadoop.apache.org by "Eric Sirianni (JIRA)" <ji...@apache.org> on 2013/12/13 16:53:07 UTC
[jira] [Commented] (HDFS-5484) StorageType and State in
DatanodeStorageInfo in NameNode is not accurate
[ https://issues.apache.org/jira/browse/HDFS-5484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13847588#comment-13847588 ]
Eric Sirianni commented on HDFS-5484:
-------------------------------------
This fix was basically nullified by the following change made via HDFS-5542
{code}
+ DatanodeStorageInfo updateStorage(DatanodeStorage s) {
synchronized (storageMap) {
DatanodeStorageInfo storage = storageMap.get(s.getStorageID());
if (storage == null) {
@@ -670,8 +658,6 @@
" for DN " + getXferAddr());
storage = new DatanodeStorageInfo(this, s);
storageMap.put(s.getStorageID(), storage);
- } else {
- storage.setState(s.getState());
}
return storage;
}
{code}
Is there a reason that 'else' was removed? By no longer updating the state in the {{BlockReport}} processing path, we effectively get the bogus state & type that is set via the first heartbeat (see the fix for HDFS-5455):
{code}
+ if (storage == null) {
+ // This is seen during cluster initialization when the heartbeat
+ // is received before the initial block reports from each storage.
+ storage = updateStorage(new DatanodeStorage(report.getStorageID()));
{code}
Even reverting the change and reintroducing the 'else' leaves the state & type temporarily inaccurate until the first block report. Wouldn't a better fix be to simply include the full {{DatanodeStorage}} object in the {{StorageReport}} (as opposed to only the Storage ID)?
As a matter of bookkeeping, should I reopen this JIRA, or would you prefer a new one be created?
> StorageType and State in DatanodeStorageInfo in NameNode is not accurate
> ------------------------------------------------------------------------
>
> Key: HDFS-5484
> URL: https://issues.apache.org/jira/browse/HDFS-5484
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: datanode
> Affects Versions: Heterogeneous Storage (HDFS-2832)
> Reporter: Eric Sirianni
> Fix For: Heterogeneous Storage (HDFS-2832)
>
> Attachments: HDFS-5484-HDFS-2832--2.patch, HDFS-5484-HDFS-2832.patch
>
>
> The fields in DatanodeStorageInfo are updated from two distinct paths:
> # block reports
> # storage reports (via heartbeats)
> The {{state}} and {{storageType}} fields are updated via the Block Report. However, as seen in the code blow, these fields are populated from a "dummy" {{DatanodeStorage}} object constructed in the DataNode:
> {code}
> BPServiceActor.blockReport() {
> //...
> // Dummy DatanodeStorage object just for sending the block report.
> DatanodeStorage dnStorage = new DatanodeStorage(storageID);
> //...
> }
> {code}
> The net effect is that the {{state}} and {{storageType}} fields are always the default of {{NORMAL}} and {{DISK}} in the NameNode.
> The recommended fix is to change {{FsDatasetSpi.getBlockReports()}} from:
> {code}
> public Map<String, BlockListAsLongs> getBlockReports(String bpid);
> {code}
> to:
> {code}
> public Map<DatanodeStorage, BlockListAsLongs> getBlockReports(String bpid);
> {code}
> thereby allowing {{BPServiceActor}} to send the "real" {{DatanodeStorage}} object with the block report.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)