[
https://issues.apache.org/jira/browse/HDFS-14515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei-Chiu Chuang updated HDFS-14515:
-----------------------------------
Status: Patch Available (was: Open)
> The proto type of quota should change to int64.
> -----------------------------------------------
>
> Key: HDFS-14515
> URL: https://issues.apache.org/jira/browse/HDFS-14515
> Project: Hadoop HDFS
> Issue Type: Improvement
> Reporter: Jinglun
> Assignee: Jinglun
> Priority: Major
> Attachments: INode.proto, Main.java, NINode.proto
>
>
> In fsimage.proto, the proto type of quota should be int64 rather than uint64.
> In proto, uint64 represents 64 bits unsinged intergers. Since quota in image
> could be -1, using uint64 is inappropriate.(see
> https://developers.google.com/protocol-buffers/docs/proto#scalar)
> HDFS uses uint64 for quota and works fine because the java type corresponding
> to uint64 is long, the same as int64. But in c++ and go uint64 and int64 are
> mapping to different types. It would be a problem when loading an image with
> c++ and fsimage.proto.
> The good news is we can simply change uint64 to int64 without breaking any
> existing clusters. The two types, int64 and uint64, are serialized
> to/deserialized from java long in the same way. Which means a long serialized
> to uint64 could be treated as int64 and deserialized to the same long value.
> 1）long a -> uint64 serialized -> byte[] b -> int64 deserialized -> long c；
> 2）a == c；
> I did a test to show 1 & 2. INode.proto uses uint64 and NINode.proto uses
> int64. Main.java shows serializing long as uint64 to byte array and
> deserializing the array as int64 to long. Using proto2.5 to compile the proto
> files.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
