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 Mon, 27 Jan 2014 14:45:44 GMT

    [ https://issues.apache.org/jira/browse/HDFS-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882848#comment-13882848
] 

Daryn Sharp commented on HDFS-5698:
-----------------------------------

I like the premise of this jira but like Kihwal, I too am interested in the performance/size
impacts.  My concern is edit logging is already imposing a non-trivial penalty to throughput.
 The longer we spend constructing an edit log entry, the longer the namespace is write locked.
 The larger the edits, the fewer edit log entries can be batched synced which both incurs
more i/o penalties and ties up the rpc handler threads longer.  It would be nice if you would
gather some statistics.

> 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
>
>
> 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)

Mime
View raw message