[
https://issues.apache.org/jira/browse/HADOOP-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466845
]
Andrzej Bialecki commented on HADOOP-915:
------------------------------------------
Good points - this tool originated as a quick hack to save a corrupted FS, so I
simply copy&pasted most of it from FSEditLog. Refactoring it is not a high
priority for me, so if you wish to tackle this you are welcome. ;)
Re: 2. - well, unknown opcode means we advance the stream by exactly 1 byte. If
there was an intermittent corruption, then sooner or later there is a chance we
get synchronized back with the next valid edit record. However, if we encounter
a garbage byte that is accidentally equal to a valid opcode then the tool will
explode ... sure, we could give up here, but we could also use DataInput.mark()
to backtrack to the last position, skip one byte, and try the next byte. I'm
not sure if it's worth the effort, though ...
> FSEditLog dump/restore tool
> ---------------------------
>
> Key: HADOOP-915
> URL: https://issues.apache.org/jira/browse/HADOOP-915
> Project: Hadoop
> Issue Type: Improvement
> Components: dfs
> Affects Versions: 0.11.0
> Reporter: Andrzej Bialecki
> Priority: Minor
> Fix For: 0.11.0
>
> Attachments: FSEditLogTool.java
>
>
> This tool is useful if your DFS has problems due to a corrupted edit log. You
> can convert the binary "edits" file into a well-formatted text file, make any
> corrections to edit commands that you think are likely to fix the problem,
> and then convert the text file back to a binary "edits" file.
> NOTE: obviously if you are not careful you can damage your DFS beyond any
> hope of repair.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
