[jira] [Updated] (HDFS-1981) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing
[ https://issues.apache.org/jira/browse/HDFS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uma Maheswara Rao G updated HDFS-1981: -- Status: Open (was: Patch Available) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing -- Key: HDFS-1981 URL: https://issues.apache.org/jira/browse/HDFS-1981 Project: Hadoop HDFS Issue Type: Bug Components: name-node Affects Versions: 0.22.0 Environment: Linux Reporter: ramkrishna.s.vasudevan Assignee: Uma Maheswara Rao G Priority: Blocker Fix For: 0.22.0 Attachments: HDFS-1981-1.patch, HDFS-1981-2.patch, HDFS-1981.patch, HDFS-1981_0.23.patch This scenario is applicable in NN and BNN case. When the namenode goes down after creating the edits.new, on subsequent restart the divertFileStreams will not happen to edits.new as the edits.new file is already present and the size is zero. so on trying to saveCheckPoint an exception occurs 2011-05-23 16:38:57,476 WARN org.mortbay.log: /getimage: java.io.IOException: GetImage failed. java.io.IOException: Namenode has an edit log with timestamp of 2011-05-23 16:38:56 but new checkpoint was created using editlog with timestamp 2011-05-23 16:37:30. Checkpoint Aborted. This is a bug or is that the behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1981) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing
[ https://issues.apache.org/jira/browse/HDFS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uma Maheswara Rao G updated HDFS-1981: -- Attachment: HDFS-1981_0.22.patch When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing -- Key: HDFS-1981 URL: https://issues.apache.org/jira/browse/HDFS-1981 Project: Hadoop HDFS Issue Type: Bug Components: name-node Affects Versions: 0.22.0 Environment: Linux Reporter: ramkrishna.s.vasudevan Assignee: Uma Maheswara Rao G Priority: Blocker Fix For: 0.22.0 Attachments: HDFS-1981-1.patch, HDFS-1981-2.patch, HDFS-1981.patch, HDFS-1981_0.22.patch, HDFS-1981_0.23.patch This scenario is applicable in NN and BNN case. When the namenode goes down after creating the edits.new, on subsequent restart the divertFileStreams will not happen to edits.new as the edits.new file is already present and the size is zero. so on trying to saveCheckPoint an exception occurs 2011-05-23 16:38:57,476 WARN org.mortbay.log: /getimage: java.io.IOException: GetImage failed. java.io.IOException: Namenode has an edit log with timestamp of 2011-05-23 16:38:56 but new checkpoint was created using editlog with timestamp 2011-05-23 16:37:30. Checkpoint Aborted. This is a bug or is that the behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1981) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing
[ https://issues.apache.org/jira/browse/HDFS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uma Maheswara Rao G updated HDFS-1981: -- Status: Patch Available (was: Open) Updated the patch for 0.22 version. When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing -- Key: HDFS-1981 URL: https://issues.apache.org/jira/browse/HDFS-1981 Project: Hadoop HDFS Issue Type: Bug Components: name-node Affects Versions: 0.22.0 Environment: Linux Reporter: ramkrishna.s.vasudevan Assignee: Uma Maheswara Rao G Priority: Blocker Fix For: 0.22.0 Attachments: HDFS-1981-1.patch, HDFS-1981-2.patch, HDFS-1981.patch, HDFS-1981_0.22.patch, HDFS-1981_0.23.patch This scenario is applicable in NN and BNN case. When the namenode goes down after creating the edits.new, on subsequent restart the divertFileStreams will not happen to edits.new as the edits.new file is already present and the size is zero. so on trying to saveCheckPoint an exception occurs 2011-05-23 16:38:57,476 WARN org.mortbay.log: /getimage: java.io.IOException: GetImage failed. java.io.IOException: Namenode has an edit log with timestamp of 2011-05-23 16:38:56 but new checkpoint was created using editlog with timestamp 2011-05-23 16:37:30. Checkpoint Aborted. This is a bug or is that the behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1981) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing
[ https://issues.apache.org/jira/browse/HDFS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Shvachko updated HDFS-1981: -- Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. Thanks Uma. I agree with Todd this is mostly targeted for 0.22, but had to follow the procedures so committed to both trunk and the branch. When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing -- Key: HDFS-1981 URL: https://issues.apache.org/jira/browse/HDFS-1981 Project: Hadoop HDFS Issue Type: Bug Components: name-node Affects Versions: 0.22.0 Environment: Linux Reporter: ramkrishna.s.vasudevan Assignee: Uma Maheswara Rao G Priority: Blocker Fix For: 0.22.0 Attachments: HDFS-1981-1.patch, HDFS-1981-2.patch, HDFS-1981.patch, HDFS-1981_0.22.patch, HDFS-1981_0.23.patch This scenario is applicable in NN and BNN case. When the namenode goes down after creating the edits.new, on subsequent restart the divertFileStreams will not happen to edits.new as the edits.new file is already present and the size is zero. so on trying to saveCheckPoint an exception occurs 2011-05-23 16:38:57,476 WARN org.mortbay.log: /getimage: java.io.IOException: GetImage failed. java.io.IOException: Namenode has an edit log with timestamp of 2011-05-23 16:38:56 but new checkpoint was created using editlog with timestamp 2011-05-23 16:37:30. Checkpoint Aborted. This is a bug or is that the behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1981) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing
[ https://issues.apache.org/jira/browse/HDFS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uma Maheswara Rao G updated HDFS-1981: -- Attachment: HDFS-1981_0.23.patch When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing -- Key: HDFS-1981 URL: https://issues.apache.org/jira/browse/HDFS-1981 Project: Hadoop HDFS Issue Type: Bug Components: name-node Affects Versions: 0.22.0 Environment: Linux Reporter: ramkrishna.s.vasudevan Priority: Blocker Fix For: 0.22.0 Attachments: HDFS-1981-1.patch, HDFS-1981-2.patch, HDFS-1981.patch, HDFS-1981_0.23.patch This scenario is applicable in NN and BNN case. When the namenode goes down after creating the edits.new, on subsequent restart the divertFileStreams will not happen to edits.new as the edits.new file is already present and the size is zero. so on trying to saveCheckPoint an exception occurs 2011-05-23 16:38:57,476 WARN org.mortbay.log: /getimage: java.io.IOException: GetImage failed. java.io.IOException: Namenode has an edit log with timestamp of 2011-05-23 16:38:56 but new checkpoint was created using editlog with timestamp 2011-05-23 16:37:30. Checkpoint Aborted. This is a bug or is that the behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1981) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing
[ https://issues.apache.org/jira/browse/HDFS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uma Maheswara Rao G updated HDFS-1981: -- Status: Open (was: Patch Available) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing -- Key: HDFS-1981 URL: https://issues.apache.org/jira/browse/HDFS-1981 Project: Hadoop HDFS Issue Type: Bug Components: name-node Affects Versions: 0.22.0 Environment: Linux Reporter: ramkrishna.s.vasudevan Priority: Blocker Fix For: 0.22.0 Attachments: HDFS-1981-1.patch, HDFS-1981-2.patch, HDFS-1981.patch, HDFS-1981_0.23.patch This scenario is applicable in NN and BNN case. When the namenode goes down after creating the edits.new, on subsequent restart the divertFileStreams will not happen to edits.new as the edits.new file is already present and the size is zero. so on trying to saveCheckPoint an exception occurs 2011-05-23 16:38:57,476 WARN org.mortbay.log: /getimage: java.io.IOException: GetImage failed. java.io.IOException: Namenode has an edit log with timestamp of 2011-05-23 16:38:56 but new checkpoint was created using editlog with timestamp 2011-05-23 16:37:30. Checkpoint Aborted. This is a bug or is that the behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1981) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing
[
https://issues.apache.org/jira/browse/HDFS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uma Maheswara Rao G updated HDFS-1981:
--
Assignee: Uma Maheswara Rao G
Status: Patch Available (was: Open)
Hi Konstantin,
Thanks for the comments.
Updated the patch on trunk.
I did not remove the getStorage API, because in latest trunk i can see that api
in FSImage class.
{code}
public NNStorage getStorage() {
return storage;
}
{code}
When namenode goes down while checkpointing and if is started again
subsequent Checkpointing is always failing
--
Key: HDFS-1981
URL: https://issues.apache.org/jira/browse/HDFS-1981
Project: Hadoop HDFS
Issue Type: Bug
Components: name-node
Affects Versions: 0.22.0
Environment: Linux
Reporter: ramkrishna.s.vasudevan
Assignee: Uma Maheswara Rao G
Priority: Blocker
Fix For: 0.22.0
Attachments: HDFS-1981-1.patch, HDFS-1981-2.patch, HDFS-1981.patch,
HDFS-1981_0.23.patch
This scenario is applicable in NN and BNN case.
When the namenode goes down after creating the edits.new, on subsequent
restart the divertFileStreams will not happen to edits.new as the edits.new
file is already present and the size is zero.
so on trying to saveCheckPoint an exception occurs
2011-05-23 16:38:57,476 WARN org.mortbay.log: /getimage: java.io.IOException:
GetImage failed. java.io.IOException: Namenode has an edit log with timestamp
of 2011-05-23 16:38:56 but new checkpoint was created using editlog with
timestamp 2011-05-23 16:37:30. Checkpoint Aborted.
This is a bug or is that the behaviour.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1981) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing
[ https://issues.apache.org/jira/browse/HDFS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HDFS-1981: - Status: Open (was: Patch Available) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing -- Key: HDFS-1981 URL: https://issues.apache.org/jira/browse/HDFS-1981 Project: Hadoop HDFS Issue Type: Bug Components: name-node Affects Versions: 0.22.0 Environment: Linux Reporter: ramkrishna.s.vasudevan Priority: Blocker Fix For: 0.22.0 Attachments: HDFS-1981-1.patch, HDFS-1981-2.patch, HDFS-1981.patch This scenario is applicable in NN and BNN case. When the namenode goes down after creating the edits.new, on subsequent restart the divertFileStreams will not happen to edits.new as the edits.new file is already present and the size is zero. so on trying to saveCheckPoint an exception occurs 2011-05-23 16:38:57,476 WARN org.mortbay.log: /getimage: java.io.IOException: GetImage failed. java.io.IOException: Namenode has an edit log with timestamp of 2011-05-23 16:38:56 but new checkpoint was created using editlog with timestamp 2011-05-23 16:37:30. Checkpoint Aborted. This is a bug or is that the behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1981) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing
[ https://issues.apache.org/jira/browse/HDFS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HDFS-1981: - Attachment: HDFS-1981-2.patch When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing -- Key: HDFS-1981 URL: https://issues.apache.org/jira/browse/HDFS-1981 Project: Hadoop HDFS Issue Type: Bug Components: name-node Affects Versions: 0.22.0 Environment: Linux Reporter: ramkrishna.s.vasudevan Priority: Blocker Fix For: 0.22.0 Attachments: HDFS-1981-1.patch, HDFS-1981-2.patch, HDFS-1981.patch This scenario is applicable in NN and BNN case. When the namenode goes down after creating the edits.new, on subsequent restart the divertFileStreams will not happen to edits.new as the edits.new file is already present and the size is zero. so on trying to saveCheckPoint an exception occurs 2011-05-23 16:38:57,476 WARN org.mortbay.log: /getimage: java.io.IOException: GetImage failed. java.io.IOException: Namenode has an edit log with timestamp of 2011-05-23 16:38:56 but new checkpoint was created using editlog with timestamp 2011-05-23 16:37:30. Checkpoint Aborted. This is a bug or is that the behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1981) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing
[ https://issues.apache.org/jira/browse/HDFS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HDFS-1981: - Status: Patch Available (was: Open) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing -- Key: HDFS-1981 URL: https://issues.apache.org/jira/browse/HDFS-1981 Project: Hadoop HDFS Issue Type: Bug Components: name-node Affects Versions: 0.22.0 Environment: Linux Reporter: ramkrishna.s.vasudevan Priority: Blocker Fix For: 0.22.0 Attachments: HDFS-1981-1.patch, HDFS-1981-2.patch, HDFS-1981.patch This scenario is applicable in NN and BNN case. When the namenode goes down after creating the edits.new, on subsequent restart the divertFileStreams will not happen to edits.new as the edits.new file is already present and the size is zero. so on trying to saveCheckPoint an exception occurs 2011-05-23 16:38:57,476 WARN org.mortbay.log: /getimage: java.io.IOException: GetImage failed. java.io.IOException: Namenode has an edit log with timestamp of 2011-05-23 16:38:56 but new checkpoint was created using editlog with timestamp 2011-05-23 16:37:30. Checkpoint Aborted. This is a bug or is that the behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1981) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing
[ https://issues.apache.org/jira/browse/HDFS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HDFS-1981: - Status: Open (was: Patch Available) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing -- Key: HDFS-1981 URL: https://issues.apache.org/jira/browse/HDFS-1981 Project: Hadoop HDFS Issue Type: Bug Components: name-node Affects Versions: 0.22.0 Environment: Linux Reporter: ramkrishna.s.vasudevan Priority: Blocker Fix For: 0.22.0 Attachments: HDFS-1981-1.patch, HDFS-1981.patch This scenario is applicable in NN and BNN case. When the namenode goes down after creating the edits.new, on subsequent restart the divertFileStreams will not happen to edits.new as the edits.new file is already present and the size is zero. so on trying to saveCheckPoint an exception occurs 2011-05-23 16:38:57,476 WARN org.mortbay.log: /getimage: java.io.IOException: GetImage failed. java.io.IOException: Namenode has an edit log with timestamp of 2011-05-23 16:38:56 but new checkpoint was created using editlog with timestamp 2011-05-23 16:37:30. Checkpoint Aborted. This is a bug or is that the behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1981) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing
[ https://issues.apache.org/jira/browse/HDFS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HDFS-1981: - Attachment: HDFS-1981-1.patch When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing -- Key: HDFS-1981 URL: https://issues.apache.org/jira/browse/HDFS-1981 Project: Hadoop HDFS Issue Type: Bug Components: name-node Affects Versions: 0.22.0 Environment: Linux Reporter: ramkrishna.s.vasudevan Priority: Blocker Fix For: 0.22.0 Attachments: HDFS-1981-1.patch, HDFS-1981.patch This scenario is applicable in NN and BNN case. When the namenode goes down after creating the edits.new, on subsequent restart the divertFileStreams will not happen to edits.new as the edits.new file is already present and the size is zero. so on trying to saveCheckPoint an exception occurs 2011-05-23 16:38:57,476 WARN org.mortbay.log: /getimage: java.io.IOException: GetImage failed. java.io.IOException: Namenode has an edit log with timestamp of 2011-05-23 16:38:56 but new checkpoint was created using editlog with timestamp 2011-05-23 16:37:30. Checkpoint Aborted. This is a bug or is that the behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1981) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing
[ https://issues.apache.org/jira/browse/HDFS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HDFS-1981: - Status: Patch Available (was: Open) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing -- Key: HDFS-1981 URL: https://issues.apache.org/jira/browse/HDFS-1981 Project: Hadoop HDFS Issue Type: Bug Components: name-node Affects Versions: 0.22.0 Environment: Linux Reporter: ramkrishna.s.vasudevan Priority: Blocker Fix For: 0.22.0 Attachments: HDFS-1981-1.patch, HDFS-1981.patch This scenario is applicable in NN and BNN case. When the namenode goes down after creating the edits.new, on subsequent restart the divertFileStreams will not happen to edits.new as the edits.new file is already present and the size is zero. so on trying to saveCheckPoint an exception occurs 2011-05-23 16:38:57,476 WARN org.mortbay.log: /getimage: java.io.IOException: GetImage failed. java.io.IOException: Namenode has an edit log with timestamp of 2011-05-23 16:38:56 but new checkpoint was created using editlog with timestamp 2011-05-23 16:37:30. Checkpoint Aborted. This is a bug or is that the behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1981) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing
[ https://issues.apache.org/jira/browse/HDFS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HDFS-1981: - Status: Patch Available (was: Open) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing -- Key: HDFS-1981 URL: https://issues.apache.org/jira/browse/HDFS-1981 Project: Hadoop HDFS Issue Type: Bug Components: name-node Affects Versions: 0.23.0 Environment: Linux Reporter: ramkrishna.s.vasudevan Fix For: 0.23.0 Attachments: HDFS-1981.patch This scenario is applicable in NN and BNN case. When the namenode goes down after creating the edits.new, on subsequent restart the divertFileStreams will not happen to edits.new as the edits.new file is already present and the size is zero. so on trying to saveCheckPoint an exception occurs 2011-05-23 16:38:57,476 WARN org.mortbay.log: /getimage: java.io.IOException: GetImage failed. java.io.IOException: Namenode has an edit log with timestamp of 2011-05-23 16:38:56 but new checkpoint was created using editlog with timestamp 2011-05-23 16:37:30. Checkpoint Aborted. This is a bug or is that the behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1981) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing
[ https://issues.apache.org/jira/browse/HDFS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HDFS-1981: - Attachment: HDFS-1981.patch When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing -- Key: HDFS-1981 URL: https://issues.apache.org/jira/browse/HDFS-1981 Project: Hadoop HDFS Issue Type: Bug Components: name-node Affects Versions: 0.23.0 Environment: Linux Reporter: ramkrishna.s.vasudevan Fix For: 0.23.0 Attachments: HDFS-1981.patch This scenario is applicable in NN and BNN case. When the namenode goes down after creating the edits.new, on subsequent restart the divertFileStreams will not happen to edits.new as the edits.new file is already present and the size is zero. so on trying to saveCheckPoint an exception occurs 2011-05-23 16:38:57,476 WARN org.mortbay.log: /getimage: java.io.IOException: GetImage failed. java.io.IOException: Namenode has an edit log with timestamp of 2011-05-23 16:38:56 but new checkpoint was created using editlog with timestamp 2011-05-23 16:37:30. Checkpoint Aborted. This is a bug or is that the behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1981) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing
[ https://issues.apache.org/jira/browse/HDFS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Shvachko updated HDFS-1981: -- Priority: Blocker (was: Major) Affects Version/s: (was: 0.23.0) 0.22.0 Fix Version/s: (was: 0.23.0) 0.22.0 I have seen this bug in 0.22. Making it a blocker. Will review the patch [very] soon. When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing -- Key: HDFS-1981 URL: https://issues.apache.org/jira/browse/HDFS-1981 Project: Hadoop HDFS Issue Type: Bug Components: name-node Affects Versions: 0.22.0 Environment: Linux Reporter: ramkrishna.s.vasudevan Priority: Blocker Fix For: 0.22.0 Attachments: HDFS-1981.patch This scenario is applicable in NN and BNN case. When the namenode goes down after creating the edits.new, on subsequent restart the divertFileStreams will not happen to edits.new as the edits.new file is already present and the size is zero. so on trying to saveCheckPoint an exception occurs 2011-05-23 16:38:57,476 WARN org.mortbay.log: /getimage: java.io.IOException: GetImage failed. java.io.IOException: Namenode has an edit log with timestamp of 2011-05-23 16:38:56 but new checkpoint was created using editlog with timestamp 2011-05-23 16:37:30. Checkpoint Aborted. This is a bug or is that the behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1981) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing
[ https://issues.apache.org/jira/browse/HDFS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HDFS-1981: - Hadoop Flags: (was: [Reviewed]) When namenode goes down while checkpointing and if is started again subsequent Checkpointing is always failing -- Key: HDFS-1981 URL: https://issues.apache.org/jira/browse/HDFS-1981 Project: Hadoop HDFS Issue Type: Bug Components: name-node Affects Versions: 0.23.0 Environment: Linux Reporter: ramkrishna.s.vasudevan Fix For: 0.23.0 This scenario is applicable in NN and BNN case. When the namenode goes down after creating the edits.new, on subsequent restart the divertFileStreams will not happen to edits.new as the edits.new file is already present and the size is zero. so on trying to saveCheckPoint an exception occurs 2011-05-23 16:38:57,476 WARN org.mortbay.log: /getimage: java.io.IOException: GetImage failed. java.io.IOException: Namenode has an edit log with timestamp of 2011-05-23 16:38:56 but new checkpoint was created using editlog with timestamp 2011-05-23 16:37:30. Checkpoint Aborted. This is a bug or is that the behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
