[
https://issues.apache.org/jira/browse/HDFS-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628057#comment-13628057
]
Kihwal Lee commented on HDFS-4489:
----------------------------------
bq. With this change, it is expected that NN is allocated more memory, say 5%.
If this is done I am not sure why users should be told namespace limit is X%
worse?
In many use cases, allocating more heap may not be a problem since machines
typically have more memory available. But if you approach from the view point
of owners of existing hardware that was spec'ed to hold certain size of
namespace, it can be viewed as a decrease of capacity. I am not saying it is a
showstopper. I just felt it should be given more thought.
I will review the implementation and try to understand your concerns about more
memory efficient design.
> Use InodeID as as an identifier of a file in HDFS protocols and APIs
> --------------------------------------------------------------------
>
> Key: HDFS-4489
> URL: https://issues.apache.org/jira/browse/HDFS-4489
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Reporter: Brandon Li
> Assignee: Brandon Li
>
> The benefit of using InodeID to uniquely identify a file can be multiple
> folds. Here are a few of them:
> 1. uniquely identify a file cross rename, related JIRAs include HDFS-4258,
> HDFS-4437.
> 2. modification checks in tools like distcp. Since a file could have been
> replaced or renamed to, the file name and size combination is no t reliable,
> but the combination of file id and size is unique.
> 3. id based protocol support (e.g., NFS)
> 4. to make the pluggable block placement policy use fileid instead of
> filename (HDFS-385).
--
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
