hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jing Zhao (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-6527) Edit log corruption due to defered INode removal
Date Tue, 24 Jun 2014 21:36:25 GMT

    [ https://issues.apache.org/jira/browse/HDFS-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14042720#comment-14042720

Jing Zhao commented on HDFS-6527:

Thanks for the report, [~l201514]! Actually the unit test failure can be reproduced in branch-2.4.1.

I think the patch should not be included in branch-2.4.1. In branch-2.4.1, we have the following
code in the beginning of analyzeFileState:
final INodesInPath iip = dir.getINodesInPath4Write(src);
final INodeFile pendingFile
    = checkLease(src, fileId, clientName, iip.getLastINode());
I.e., the inode is retrieved by resolving the path. Since we remove the inode from the children
list while holding the fsnamesystem lock, the race condition can actually be avoided I guess.

HDFS-6294 changed this part to load the INode from the inode map, while in FSNamesystem#deleteInternal,
the inode is removed from the inode map without holding fsnamesystem lock. I guess this is
the cause of the issue, and the issue is only in 2.5 and trunk.

> Edit log corruption due to defered INode removal
> ------------------------------------------------
>                 Key: HDFS-6527
>                 URL: https://issues.apache.org/jira/browse/HDFS-6527
>             Project: Hadoop HDFS
>          Issue Type: Bug
>    Affects Versions: 2.4.0
>            Reporter: Kihwal Lee
>            Assignee: Kihwal Lee
>            Priority: Blocker
>             Fix For: 2.4.1
>         Attachments: HDFS-6527.branch-2.4.patch, HDFS-6527.trunk.patch, HDFS-6527.v2.patch,
HDFS-6527.v3.patch, HDFS-6527.v4.patch, HDFS-6527.v5.patch
> We have seen a SBN crashing with the following error:
> {panel}
> \[Edit log tailer\] ERROR namenode.FSEditLogLoader:
> Encountered exception on operation AddBlockOp
> [path=/xxx,
> penultimateBlock=NULL, lastBlock=blk_111_111, RpcClientId=,
> RpcCallId=-2]
> java.io.FileNotFoundException: File does not exist: /xxx
> {panel}
> This was caused by the deferred removal of deleted inodes from the inode map. Since getAdditionalBlock()
acquires FSN read lock and then write lock, a deletion can happen in between. Because of deferred
inode removal outside FSN write lock, getAdditionalBlock() can get the deleted inode from
the inode map with FSN write lock held. This allow addition of a block to a deleted file.
> As a result, the edit log will contain OP_ADD, OP_DELETE, followed by
>  OP_ADD_BLOCK.  This cannot be replayed by NN, so NN doesn't start up or SBN crashes.

This message was sent by Atlassian JIRA

View raw message