[
https://issues.apache.org/jira/browse/HDFS-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13642907#comment-13642907
]
Konstantin Shvachko commented on HDFS-4489:
-------------------------------------------
Suresh,
0.20 is not typo. You should parse it as a sarcasm, sorry. Wire compatibility
was a target for many previous releases and the train is still there.
We clearly have a disagreement about what should be in the release. Other
people may have other opinions. And that is my point.
All I ask is to play by the rules. Make a release plan and put it into vote.
See bylaws under "Release Plan". I'll be glad to discuss your plan.
Here you act like its your own branch where you commit what you want and nobody
else cares.
Does it make sense?
> 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
> Fix For: 2.0.5-beta
>
>
> 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
