hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryn Sharp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-5698) Use protobuf to serialize / deserialize FSImage
Date Tue, 28 Jan 2014 20:02:46 GMT

    [ 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

View raw message