[
https://issues.apache.org/jira/browse/HDFS-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018674#comment-13018674
]
Tsz Wo (Nicholas), SZE commented on HDFS-1822:
----------------------------------------------
> ... FBBDoAH has a custom opscode ...
Since it is not in Apache, we could simply reject the patch.
> In reality, doesn't this ultimately mean that we should not be performing
> upgrades if an editslog exists? ...
No. I suspect that there are some misunderstanding: By compatible change, it
means new codes can handle old edits.
Suresh's patch is a compatible change: It just add a functionality to read
0.20-security edits.
Again, layout version defines format, i.e. opcodes. Therefore, opcodes could
be different across layout versions.
> But there is nothing wrong with trunk. ...
After the patch, it is still nothing wrong with trunk.
Allen, you are stopping a feature, which is the ability to read 0.20-security
edits, but not stopping an incompatible change. Stopping someone's patch is
easy but making contribution becomes hard.
> Editlog opcodes overlap between 20 security and later releases
> --------------------------------------------------------------
>
> Key: HDFS-1822
> URL: https://issues.apache.org/jira/browse/HDFS-1822
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.21.0, 0.22.0, 0.23.0
> Reporter: Suresh Srinivas
> Assignee: Suresh Srinivas
> Priority: Blocker
> Fix For: 0.22.0, 0.23.0
>
> Attachments: HDFS-1822.patch
>
>
> Same opcode are used for different operations between 0.20.security, 0.22 and
> 0.23. This results in failure to load editlogs on later release, especially
> during upgrades.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
