You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-dev@hadoop.apache.org by "Daryn Sharp (JIRA)" <ji...@apache.org> on 2015/03/25 23:09:52 UTC

[jira] [Created] (HDFS-7990) IBR delete ack should not be delayed

Daryn Sharp created HDFS-7990:
---------------------------------

             Summary: IBR delete ack should not be delayed
                 Key: HDFS-7990
                 URL: https://issues.apache.org/jira/browse/HDFS-7990
             Project: Hadoop HDFS
          Issue Type: Bug
          Components: namenode
    Affects Versions: 2.0.0-alpha
            Reporter: Daryn Sharp
            Assignee: Daryn Sharp


HDFS-395 added the incremental BR feature.  A concern was avoiding a race condition with ack-ing block invalidates followed by the directory scanner re-adding the block before the async delete service removes the block, possibly resulting in a full BR that includes the previously delete ack-ed block.

The solution was to batch & delay block deletion acks via a hardcoded interval of 100 * heartbeat interval (default: 5min).  The delay isn't required:
#  The {{FSDatasetSpi}} tracks blocks pending deletions precisely so the scanner won't re-add the block to the volume map
# Block receiving, received, and deleted go into the same pending report.  A block received event will trigger an immediate IBR which includes the deletion acks.  Ie. The delay is meaningless for all but a quiescent cluster
# Failing to promptly report deleted blocks on a quiescent cluster prevents the NN from updating the block maps to remove the locations



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)