[
https://issues.apache.org/jira/browse/HADOOP-5133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679437#action_12679437
]
Konstantin Shvachko commented on HADOOP-5133:
---------------------------------------------
> 1. What should be the length of the block: longer one or shorter one?
The length doesn't matter since all replicas are corrupt. It could be the
default block size or 0.
> 2. Should the file remains to be open or could we close the file?
I think according to our policies (at least one replica of each block should be
reported) we cannot close the file. We should not wait in this case for more
replicas to appear but rather return an error to the client once the problem is
encountered.
Once again this is an error condition, and that is why it is better to let the
client know that an error occurred than to silently make a decision on his
behalf.
> FSNameSystem#addStoredBlock does not handle inconsistent block length
> correctly
> -------------------------------------------------------------------------------
>
> Key: HADOOP-5133
> URL: https://issues.apache.org/jira/browse/HADOOP-5133
> Project: Hadoop Core
> Issue Type: Bug
> Components: dfs
> Affects Versions: 0.18.2
> Reporter: Hairong Kuang
> Assignee: Hairong Kuang
> Fix For: 0.20.0
>
> Attachments: 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.
