[
https://issues.apache.org/jira/browse/HDFS-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13884531#comment-13884531
]
Daryn Sharp commented on HDFS-5698:
-----------------------------------
You may want to investigate if the inodemap will perform better with a
{{ConcurrentHashMap}} than a {{LightWeightGSet}}. That will increase the
parallelism of the map insertion. I think the gset was chosen for memory
concerns.
Assuming you plan to parallelize the parent/child linkages, I think the
{{addChild}} may need to be in a synchronized block unless the inodeMap is made
concurrent. I'm not a snapshot expert, but I wonder how thread-safe the
snapshot manager is. Are the directory diffs constructed "on the fly" during
addition of the children, or are they stored separately in the fsimage?
We just need to be certain it's actually feasible to offset a ~2X increase in
load time.
Also, did you happen to gather heap usage statistics? Is part of the load
increase maybe due to increased GC? It'll be important to know if NN's with
huge images will be unable to load their images w/o more heap allocation.
> Use protobuf to serialize / deserialize FSImage
> -----------------------------------------------
>
> Key: HDFS-5698
> URL: https://issues.apache.org/jira/browse/HDFS-5698
> Project: Hadoop HDFS
> Issue Type: Improvement
> Reporter: Haohui Mai
> Assignee: Haohui Mai
> Attachments: HDFS-5698.000.patch, HDFS-5698.001.patch
>
>
> Currently, the code serializes FSImage using in-house serialization
> mechanisms. There are a couple disadvantages of the current approach:
> # Mixing the responsibility of reconstruction and serialization /
> deserialization. The current code paths of serialization / deserialization
> have spent a lot of effort on maintaining compatibility. What is worse is
> that they are mixed with the complex logic of reconstructing the namespace,
> making the code difficult to follow.
> # Poor documentation of the current FSImage format. The format of the FSImage
> is practically defined by the implementation. An bug in implementation means
> a bug in the specification. Furthermore, it also makes writing third-party
> tools quite difficult.
> # Changing schemas is non-trivial. Adding a field in FSImage requires bumping
> the layout version every time. Bumping out layout version requires (1) the
> users to explicitly upgrade the clusters, and (2) putting new code to
> maintain backward compatibility.
> This jira proposes to use protobuf to serialize the FSImage. Protobuf has
> been used to serialize / deserialize the RPC message in Hadoop.
> Protobuf addresses all the above problems. It clearly separates the
> responsibility of serialization and reconstructing the namespace. The
> protobuf files document the current format of the FSImage. The developers now
> can add optional fields with ease, since the old code can always read the new
> FSImage.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
