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 8D5F918216 for ; Fri, 18 Dec 2015 13:45:47 +0000 (UTC) Received: (qmail 96876 invoked by uid 500); 18 Dec 2015 13:45:47 -0000 Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org Received: (qmail 96779 invoked by uid 500); 18 Dec 2015 13:45:47 -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 96656 invoked by uid 99); 18 Dec 2015 13:45:47 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Dec 2015 13:45:47 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 08A742C1F6F for ; Fri, 18 Dec 2015 13:45:47 +0000 (UTC) Date: Fri, 18 Dec 2015 13:45:47 +0000 (UTC) From: "Tsz Wo Nicholas Sze (JIRA)" To: hdfs-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Assigned] (HDFS-8999) Namenode need not wait for {{blockReceived}} for the last block before completing a file. 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-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo Nicholas Sze reassigned HDFS-8999: ----------------------------------------- Assignee: Tsz Wo Nicholas Sze > Namenode need not wait for {{blockReceived}} for the last block before completing a file. > ----------------------------------------------------------------------------------------- > > Key: HDFS-8999 > URL: https://issues.apache.org/jira/browse/HDFS-8999 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode > Reporter: Jitendra Nath Pandey > Assignee: Tsz Wo Nicholas Sze > > This comes out of a discussion in HDFS-8763. Pasting [~jingzhao]'s comment from the jira: > {quote} > ...whether we need to let NameNode wait for all the block_received msgs to announce the replica is safe. Looking into the code, now we have > # NameNode knows the DataNodes involved when initially setting up the writing pipeline > # If any DataNode fails during the writing, client bumps the GS and finally reports all the DataNodes included in the new pipeline to NameNode through the updatePipeline RPC. > # When the client received the ack for the last packet of the block (and before the client tries to close the file on NameNode), the replica has been finalized in all the DataNodes. > Then in this case, when NameNode receives the close request from the client, the NameNode already knows the latest replicas for the block. Currently the checkReplication call only counts in all the replicas that NN has already received the block_received msg, but based on the above #2 and #3, it may be safe to also count in all the replicas in the BlockUnderConstructionFeature#replicas? > {quote} -- This message was sent by Atlassian JIRA (v6.3.4#6332)