[
https://issues.apache.org/jira/browse/HDFS-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616319#comment-13616319
]
Kihwal Lee commented on HDFS-4645:
----------------------------------
bq. This seems fine to me in the abstract, though I'm not sure what the
original motivation of randomly generating the IDs was.
Bucketizing or distributing blocks based on block numbers. Sorting based on
block numbers to get a ramdom block ordering. I think the repl queue did this.
I don't know if it still does it.
bq. One challenge with implementing this will be how to do upgrades from
existing clusters which already have block IDs randomly distributed across the
valid range. Any thoughts on how to handle that?
I am not concerned about block id collision within namenode. Even for a large
name space, the id space is very sparsely populated. Between datanode and
namenode, generation number will resolve any conflict. I am more worried about
components that depend on the randomness of block ids, which will make upgrade
hard.
Will new block ids be allowed to be < 0?
> Move from randomly generated block ID to sequentially generated block ID
> ------------------------------------------------------------------------
>
> Key: HDFS-4645
> URL: https://issues.apache.org/jira/browse/HDFS-4645
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: namenode
> Affects Versions: 3.0.0
> Reporter: Suresh Srinivas
> Assignee: Suresh Srinivas
>
> Currently block IDs are randomly generated. This means there is no pattern to
> block ID generation and no guarantees such as uniqueness of block ID for the
> life time of the system can be made. I propose using SequentialNumber for
> block ID generation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
