[
https://issues.apache.org/jira/browse/HDFS-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613338#comment-13613338
]
Suresh Srinivas commented on HDFS-4489:
---------------------------------------
bq. At one point in time I believe the INodeID work did indeed break WebHDFS on
trunk.
That is because of a bug introduced in the change. When I say *break* in my
previous comment, it is breaking the functionality because incomplete set of
changes where HDFS is not functional and not a bug in the code committed.
bq. I don't understand the resistance to doing this on a feature branch. What's
the concern with doing so?
I am not resisting it, I do not see a need for it. I believe we have two more
jiras to go in. Other jiras are already in. I think moving those commits to a
separate branch, adding mere two more commits in that branch, calling for merge
vote is unnecessary waste of time and I want to avoid it.
> 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
