hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vinod Kumar Vavilapalli (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-8498) Blocks can be committed with wrong size
Date Wed, 30 Mar 2016 23:30:25 GMT

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

Vinod Kumar Vavilapalli commented on HDFS-8498:
-----------------------------------------------

[~zhz] / [~kihwal] / [~daryn], I think we should close this as Won't fix or as a dup of HDFS-9289.

This bug keeps appearing in the blocker/critical list for releases, but we don't seem to be
progressing.


> 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: Daryn Sharp
>            Priority: Critical
>
> 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.4#6332)

Mime
View raw message