[
https://issues.apache.org/jira/browse/HDFS-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14697787#comment-14697787
]
Jing Zhao commented on HDFS-8801:
---------------------------------
Actually converting BlockInfoUnderConstruction can bring us some benefits.
Currently when processing block reports, if a finalized replica is reported, we
may replace the corresponding UC blockInfo object with a newly created complete
blockInfo object inside of the INodeFile. This replacement mixes the states of
the block storage management and the NameSystem management, and forces the
block report processing to take the Namesystem write lock.
To convert BlockInfoUC as a feature can avoid the BlockInfo object replacement.
It helps separating the storage level and file system level, and allows us to
do further block report processing improvement (e.g., separating the lock for
namesystem and blockmanager).
> Convert BlockInfoUnderConstruction as a feature
> -----------------------------------------------
>
> Key: HDFS-8801
> URL: https://issues.apache.org/jira/browse/HDFS-8801
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: namenode
> Affects Versions: 2.7.1
> Reporter: Zhe Zhang
>
> Per discussion under HDFS-8499, with the erasure coding feature, there will
> be 4 types of {{BlockInfo}} forming a multi-inheritance:
> {{complete+contiguous}}, {{complete+striping}}, {{UC+contiguous}},
> {{UC+striped}}. We had the same challenge with {{INodeFile}} and the solution
> was building feature classes like {{FileUnderConstructionFeature}}. This JIRA
> aims to implement the same idea on {{BlockInfo}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
