Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 23 Feb 2017 19:46:44 +0000 (UTC)
From: "Wei-Chiu Chuang (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12833818.1432911640000.46989.1487879204274@Atlassian.JIRA>
In-Reply-To: <JIRA.12833818.1432911640000@Atlassian.JIRA>
References: <JIRA.12833818.1432911640000@Atlassian.JIRA> <JIRA.12833818.1432911640868@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HDFS-8498) Blocks can be committed with wrong
 size
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 23 Feb 2017 19:47:19 -0000


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

Wei-Chiu Chuang commented on HDFS-8498:
---------------------------------------

Thanks very much for your branch-2 patch, Jing. I plan to review it today.

> Blocks can be committed with wrong size
> ---------------------------------------
>
>                 Key: HDFS-8498
>                 URL: https://issues.apache.org/jira/browse/HDFS-8498
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: namenode
>    Affects Versions: 2.5.0
>            Reporter: Daryn Sharp
>            Assignee: Jing Zhao
>            Priority: Critical
>             Fix For: 3.0.0-alpha3
>
>         Attachments: HDFS-8498.000.patch, HDFS-8498.001.patch, HDFS-8498.branch-2.patch
>
>
> When an IBR for a UC block arrives, the NN updates the expected location's block and replica state _only_ if it's on an unexpected storage for an expected DN.  If it's for an expected storage, only the genstamp is updated.  When the block is committed, and the expected locations are verified, only the genstamp is checked.  The size is not checked but it wasn't updated in the expected locations anyway.
> A faulty client may misreport the size when committing the block.  The block is effectively corrupted.  If the NN issues replications, the received IBR is considered corrupt, the NN invalidates the block, immediately issues another replication.  The NN eventually realizes all the original replicas are corrupt after full BRs are received from the original DNs.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org