[ https://issues.apache.org/jira/browse/HDFS-4923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690744#comment-13690744 ]
Suresh Srinivas commented on HDFS-4923: --------------------------------------- bq. In general though, I'm in favor of giving the admin flexibility. I'd rather not block exit on writing out a multi-GB file. This might actually make overall restart time slower if there aren't many edits. I think this probably is less of a concern. Either you save the namespace when you stop the namenode or when you start the namenode. The cost of writing multi-GB file cannot be avoided, at least as of now. bq. My $0.02, definitely, but this should be default 'true'. I agree. > Save namespace when the namenode is stopped > ------------------------------------------- > > Key: HDFS-4923 > URL: https://issues.apache.org/jira/browse/HDFS-4923 > Project: Hadoop HDFS > Issue Type: Improvement > Affects Versions: 3.0.0 > Reporter: Suresh Srinivas > Assignee: Suresh Srinivas > > In rare instances the namenode fails to load editlog due to corruption during > startup. This has more severe impact if editlog segment to be checkpointed > has corruption, as checkpointing fails because the editlog with corruption > cannot be consumed. If an administrator does not notice this and address it > by saving the namespace, recovering the namespace would involve complex file > editing, using previous backups or losing last set of modifications. > The other issue that also happens frequently is, checkpointing fails and has > not happened for a long time, resulting in long editlogs and even corrupt > editlogs. > To handle these issues, when namenode is stopped, we can put it in safemode > and save the namespace, before the process is shutdown. As an added benefit, > the namenode restart would be faster, given there is no editlog to consume. > What do folks think? -- 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