[
https://issues.apache.org/jira/browse/HDFS-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13540362#comment-13540362
]
Brandon Li commented on HDFS-4334:
----------------------------------
{quote}I have one comment. The INodeId code is practically identical to
GenerationStamp class modular some members rename. It would be good to factor
out a common class something like SequentialLongGenerator or
UniqueueLongGenerator and subclass it in both INodeId and GenerationStamp. It
will be also useful for sequential block id generator if we ever get to
it.{quote}
Sounds good.
{quote}And one question. This issue only adds the inode id, but does not
provide ways to actually access the INode via it's id, right? And then what is
the plan for accessing INodes via ids?{quote}
The plan is to have an in-memory mapping from inodeId to inode. Suppose one
entry takes minimal 8 bytes, ~80MB is required for 1000 million inodes.
> Add a unique id to each INode
> -----------------------------
>
> Key: HDFS-4334
> URL: https://issues.apache.org/jira/browse/HDFS-4334
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: namenode
> Reporter: Brandon Li
> Assignee: Brandon Li
> Attachments: HDFS-4334.patch, HDFS-4334.patch, HDFS-4334.patch
>
>
> This JIRA is to track the task to add inode id, which is a 64bit number.
> Unlike many local file systems, HDFS doesn't recycle inode id.
--
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
