[
https://issues.apache.org/jira/browse/HDFS-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229431#comment-13229431
]
Colin Patrick McCabe commented on HDFS-3004:
--------------------------------------------
bq. Why would a user choose "always choose 1st"?
A user would choose this option if he was in a hurry and wanted the recovery
tool to choose the "normal" or most typical option. It's similar to fsck -a.
bq. Per above, What is the "TODO: attempt to resynchronize stream here" for?
Basically, this TODO is to remind me to implement skipping. I was originally
hoping to get this patch in first, although I guess the patches could be
combined. Perhaps I will actually implement it in the next rev-- it's simple
enough.
bq. Should the catch of Throwable catch IOException like it used to? We're not
trying to catch new types of exceptions in the non-recovery case right?
The rationale behind catching throwable is that we don't know exactly what
kinds of exceptions dirty data may cause the parsing code to throw. I think
this is explained in a comment:
{code}
// Catch Throwable and not just IOE, since bad edits may generate
// NumberFormatExceptions, AssertionErrors, OutOfMemoryErrors, etc.
{code}
I didn't add this comment-- it was there before to explain why we catch
throwable (which we have always done here, as far as I know.)
[command about dfs.namenode.num.checkpoints.retained]
Yes, I will look into this...
[testing comments]
I'll see if I can add a few more unit tests. I did run this manually a few
times.
> Implement Recovery Mode
> -----------------------
>
> Key: HDFS-3004
> URL: https://issues.apache.org/jira/browse/HDFS-3004
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: tools
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments: HDFS-3004.010.patch,
> HDFS-3004__namenode_recovery_tool.txt
>
>
> When the NameNode metadata is corrupt for some reason, we want to be able to
> fix it. Obviously, we would prefer never to get in this case. In a perfect
> world, we never would. However, bad data on disk can happen from time to
> time, because of hardware errors or misconfigurations. In the past we have
> had to correct it manually, which is time-consuming and which can result in
> downtime.
> Recovery mode is initialized by the system administrator. When the NameNode
> starts up in Recovery Mode, it will try to load the FSImage file, apply all
> the edits from the edits log, and then write out a new image. Then it will
> shut down.
> Unlike in the normal startup process, the recovery mode startup process will
> be interactive. When the NameNode finds something that is inconsistent, it
> will prompt the operator as to what it should do. The operator can also
> choose to take the first option for all prompts by starting up with the '-f'
> flag, or typing 'a' at one of the prompts.
> I have reused as much code as possible from the NameNode in this tool.
> Hopefully, the effort that was spent developing this will also make the
> NameNode editLog and image processing even more robust than it already is.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
