zhangshuyan0 commented on code in PR #6176:
URL: https://github.com/apache/hadoop/pull/6176#discussion_r1360562024
##########
hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeDescriptor.java:
##########
@@ -1007,6 +1013,7 @@ public void updateRegInfo(DatanodeID nodeReg) {
for(DatanodeStorageInfo storage : getStorageInfos()) {
if (storage.getStorageType() != StorageType.PROVIDED) {
storage.setBlockReportCount(0);
+ storage.setBlockContentsStale(true);
Review Comment:
@ZanderXu Thanks for your reply. I think this modification is not a new bug.
Before this patch, NameNode knows all excess replicas even though a DataNode is
re-registered, so it wouldn't delete more replicas than expected.
As the situation you just said, we can discuss it from two aspects:
1. If NameNode knows the corrupt replicas corresponding to corrupt disk, it
will not delete the only healthy replica.
2. If NameNode know nothing about the corrupt disk, the essence of the
problem is that the Admin manually removed some replicas without notifying
NameNode. Then in the time between "the replica has been removed" and "NN
learns that the replica has been removed", there is always a chance that the
only healthy replica will be deleted. So, I think the key to solving this
problem is to immediately notify NN which disk is corrupt. Restarting &
re-registering may not be necessary.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
