[
https://issues.apache.org/jira/browse/HDFS-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13642185#comment-13642185
]
Suresh Srinivas commented on HDFS-4489:
---------------------------------------
bq. My concern is that you committed incompatible change
Konstantin, not sure if you looked at the release notes. This change disallows
a file or directory name called .reserved under root. That is the only reason
why I marked it as incompatible. This is not related to wire or API
incompatibility. That said, one of the goal for 2.0.5 is drive towards a state
where incompatible changes are not allowed after it.
bq. which is a new feature and a large change, into the stabilization branch
without a vote or a release plan discussed with the community.
I agree that this is a new features. Committers routinely promote changes that
they consider are okay to branch-2. I believe this does not add to the
instability. Let me know if you disagree based on a code review/testing.
Also merging to branch-2 in a lot of cases is done based on a committer's
judgement. Please look various other jiras that are merged in without vote
thread into branch-2. I do not consider this as a large feature. However for
Snapshot feature, I would have brought up that in a release thread.
bq. . And you didn't give any reasons for the merge.
I think there is enough motivation for the feature posted in the jira.
bq. I would like to ask to revert this merge from branch 2.0.5 and follow the
procedures for merging features into new release branches if you decide to
proceed.
I have spent more than 12 hours merging the chain of jiras required and
resolving conflict before getting to 4 changes that introduced file id. Is your
concern about HDFS-4434 or all the related changes?
> 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
