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)