[
https://issues.apache.org/jira/browse/HDFS-9289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14974490#comment-14974490
]
Chang Li commented on HDFS-9289:
--------------------------------
have met another case in our cluster
{code}
2015-10-23 04:38:08,544 [IPC Server handler 11 on 8020] INFO hdfs.StateChange:
BLOCK* allocateBlock: /projects/wcc/wcc1/data/2015/10/22/05/Content-9892.temp.
gz.temp._COPYING_. BP-1161836467-98.137.240.59-1438814573258
blk_1427767166_354062734{blockUCState=UNDER_CONSTRUCTION, primaryNodeIndex=-1,
replicas=[Replica
UnderConstruction[[DISK]DS-a04f60ed-6700-4e93-8a52-555301e07d3b:NORMAL:10.213.43.41:1004|RBW],
ReplicaUnderConstruction[[DISK]DS-7e0de56b-17ba-4164-8b19-67a9
f9f84c2c:NORMAL:10.213.46.123:1004|RBW],
ReplicaUnderConstruction[[DISK]DS-14a850d1-deb9-496b-b5ed-bb57010a8b56:NORMAL:10.213.46.96:1004|RBW]]}
2015-10-23 04:39:35,588 [IPC Server handler 5 on 8020] INFO
namenode.FSNamesystem:
updatePipeline(block=BP-1161836467-98.137.240.59-1438814573258:blk_1427767
166_354062734, newGenerationStamp=354080525, newLength=24505255,
newNodes=[10.213.46.123:1004, 10.213.46.96:1004],
clientName=DFSClient_NONMAPREDUCE_12621589
81_1)
2015-10-23 04:39:35,588 [IPC Server handler 5 on 8020] INFO
namenode.FSNamesystem:
updatePipeline(BP-1161836467-98.137.240.59-1438814573258:blk_1427767166_35
4062734) successfully to
BP-1161836467-98.137.240.59-1438814573258:blk_1427767166_354080525
2015-10-23 04:39:35,595 [IPC Server handler 50 on 8020] INFO hdfs.StateChange:
DIR* completeFile:
/projects/wcc/wcc1/data/2015/10/22/05/Content-9892.temp.gz.temp._COPYING_ is
closed by DFSClient_NONMAPREDUCE_1262158981_1
{code}
This is also a complete file before a pipelineupdate.
jsp page shows three nodes which currently holds the replica of blk_1427767166.
One of the node is 10.213.43.41, which is the first node in old pipeline and
dropped out in the updated pipeline and the replica currently in that node has
old gen stamp. The other two nodes are later replicated after the first node in
old pipeline sent in its block report. The two nodes in the updated pipeline
were marked as corrupted until the node 10.213.43.41 sent in its block report.
> check genStamp when complete file
> ---------------------------------
>
> Key: HDFS-9289
> URL: https://issues.apache.org/jira/browse/HDFS-9289
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Chang Li
> Assignee: Chang Li
> Priority: Critical
> Attachments: HDFS-9289.1.patch, HDFS-9289.2.patch
>
>
> we have seen a case of corrupt block which is caused by file complete after a
> pipelineUpdate, but the file complete with the old block genStamp. This
> caused the replicas of two datanodes in updated pipeline to be viewed as
> corrupte. Propose to check genstamp when commit block
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
