[
https://issues.apache.org/jira/browse/HDFS-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022193#comment-13022193
]
Suresh Srinivas commented on HDFS-1842:
---------------------------------------
> You just need to demand that the edits is empty.
This was my first choice as well. My concern was it might throw this error
after partially upgrading to 204 and might require rollback to go back to
previous release, to save namespace. I looked at the code more closely and
rollback is not required.
There are couple of choices on how this can be done:
# If editlog file size == 0 then treat it as there are no edits. I am
reluctant to go this route. With new editlog changes, could editlog size be !=
0, but still it has no file system operation entries?
# While loading editlogs, wait for numEdits to go to 1 and then throw an error.
This means the entire fsimage is loaded, before the error is thrown. If we are
doing this we might as well go with the current patch. The opcode conversion
code then only remains in 2xx release.
> Cannot upgrade 0.20.203 to 0.21 with an editslog present
> --------------------------------------------------------
>
> Key: HDFS-1842
> URL: https://issues.apache.org/jira/browse/HDFS-1842
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: name-node
> Affects Versions: 0.20.203.0
> Reporter: Allen Wittenauer
> Priority: Blocker
> Attachments: HDFS-1842.rel203.patch, HDFS-1842.rel204.patch
>
>
> If a user installs 0.20.203 and then upgrades to 0.21 with an editslog
> present, 0.21 will corrupt the file system due to opcode re-usage.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
