Return-Path: X-Original-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EAACB11C7A for ; Mon, 16 Jun 2014 22:12:02 +0000 (UTC) Received: (qmail 21085 invoked by uid 500); 16 Jun 2014 22:12:02 -0000 Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org Received: (qmail 21033 invoked by uid 500); 16 Jun 2014 22:12:02 -0000 Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hdfs-issues@hadoop.apache.org Delivered-To: mailing list hdfs-issues@hadoop.apache.org Received: (qmail 21015 invoked by uid 99); 16 Jun 2014 22:12:02 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Jun 2014 22:12:02 +0000 Date: Mon, 16 Jun 2014 22:12:02 +0000 (UTC) From: "Jing Zhao (JIRA)" To: hdfs-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (HDFS-6527) Edit log corruption due to defered INode removal MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HDFS-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jing Zhao updated HDFS-6527: ---------------------------- Attachment: HDFS-6527.v5.patch Thanks Kihwal! The v4 patch looks good to me. But I guess the unit test now cannot cover the non-snapshot case since the inode will not be removed from the inodemap if it is still contained in a snapshot. So based on your v4 patch I added a new unit test to cover both scenarios. Also I use a customized block placement policy and use whitebox to add the deleted inode back to the inodemap so as to remove the dependency of the fault injection code. > 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 > 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 (v6.2#6252)