[
https://issues.apache.org/jira/browse/HADOOP-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466830
]
Konstantin Shvachko commented on HADOOP-915:
--------------------------------------------
This is a very useful tool. We can probably think of displaying it on the web
UI. Two comments:
1. The implementation is completely independent of the hdfs code, which makes
it a stand alone feature,
but at the same time code replication makes the feature difficult to support. I
mean if somebody changes
the layout or the set of commands it is not obvious that the same changes
should be replicated in
FSEditLogTool. I'd propose to create a method in FSEditLog that would read an
edit command from
the edits file one at a time, and reuse it in edits loading both for merging
with the image and for the
readable form conversion. You might also need to make op code constants package
private rather than
private as they are now.
2. It looks to me that if the edits file contents is corrupted (e.g. in the
middle) the tool will read till
the corrupted place and then display garbage.
Should it really keep displaying anything or just report the error and abort?
> 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.
