[ https://issues.apache.org/jira/browse/HDFS-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798972#action_12798972
]
Hadoop QA commented on HDFS-145:
--------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12429938/corruptionDetect1.patch
against trunk revision 897975.
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 3 new or modified tests.
+1 javadoc. The javadoc tool did not generate any warning messages.
-1 javac. The applied patch generated 25 javac compiler warnings (more than the trunk's
current 24 warnings).
+1 findbugs. The patch does not introduce any new Findbugs warnings.
+1 release audit. The applied patch does not increase the total number of release audit
warnings.
+1 core tests. The patch passed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results: http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-h5.grid.sp2.yahoo.net/181/testReport/
Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-h5.grid.sp2.yahoo.net/181/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-h5.grid.sp2.yahoo.net/181/artifact/trunk/build/test/checkstyle-errors.html
Console output: http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-h5.grid.sp2.yahoo.net/181/console
This message is automatically generated.
> FSNameSystem#addStoredBlock does not handle inconsistent block length correctly
> -------------------------------------------------------------------------------
>
> Key: HDFS-145
> URL: https://issues.apache.org/jira/browse/HDFS-145
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 0.21.0
> Reporter: Hairong Kuang
> Assignee: Hairong Kuang
> Fix For: 0.21.0, 0.22.0
>
> Attachments: corruptionDetect.patch, corruptionDetect1.patch, corruptionDetect2.patch,
inconsistentLen.patch, inconsistentLen1.patch, inconsistentLen2.patch
>
>
> Currently NameNode treats either the new replica or existing replicas as corrupt if the
new replica's length is inconsistent with NN recorded block length. The correct behavior should
be
> 1. For a block that is not under construction, the new replica should be marked as corrupt
if its length is inconsistent (no matter shorter or longer) with the NN recorded block length;
> 2. For an under construction block, if the new replica's length is shorter than the NN
recorded block length, the new replica could be marked as corrupt; if the new replica's length
is longer, NN should update its recorded block length. But it should not mark existing replicas
as corrupt. This is because NN recorded length for an under construction block does not accurately
match the block length on datanode disk. NN should not judge an under construction replica
to be corrupt by looking at the inaccurate information: its recorded block length.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.