[
https://issues.apache.org/jira/browse/HDFS-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458855#comment-13458855
]
Colin Patrick McCabe commented on HDFS-3954:
--------------------------------------------
bq. I'm perfectly fine with the tool throwing an exception if the input log
does not have the current layout version. Are you ok with that?
No, because the edit log code should be able to read most older formats. We
even support reading branch-1 edit logs in trunk. We have to do this in order
to implement upgrade. It's very useful to be able to read older edit logs with
oev; the fact that it can't write out older edit logs hasn't ever been a
problem for me in the past.
bq. I found this while tinkering with a layout change. A test failed in
TestOfflineEditsViewer that verifies a binary -> xml -> binary conversion
produces an identical binary edits log. The files were identical sans the
version, but the new file was "corrupt".
In that {{TestOfflineEditsViewer}} test, we could perhaps skip comparing the
first few bytes of the edit log (where the version is stored).
> OEV can generate a corrupt edits log
> ------------------------------------
>
> Key: HDFS-3954
> URL: https://issues.apache.org/jira/browse/HDFS-3954
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node, tools
> Affects Versions: 2.0.0-alpha, 3.0.0
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
>
> The offline edits viewer can output in various formats such as xml and
> binary. Xml output correctly preserves the input's layout version. Binary
> output always writes the latest layout version into the header. Converting
> an older layout to xml and back may result in a corrupt edits log.
--
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
