[ https://issues.apache.org/jira/browse/HADOOP-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Konstantin Shvachko updated HADOOP-1978: ---------------------------------------- Attachment: editsNew-0-15.patch - I fixed the problem as described above by making edits.new empty at the same time the edits gets emptied. - I truncate edits files when they are emptied, otherwise it is not clear what is the real file size. - Based on that modified TestCheckpoint, which now checks edits and image files existence and lengths. The test fails with the old code and succeeds with the new. - Cleaned up EditLogOutputStream: it calls force() now on the FileChannel instead of flush() and synch(). This makes the fd member obsolete. I removed it. - Fsck was failing consistently on my machine because safe-mode was still on when the test was trying to delete files. It should call waitActive() before deleting. - Patch for 0.14 is coming soon. - For hadoop 0.13 in order to avoid this problem one should just start the cluster with -upgrade. Then edits.new will be merged with the image as well as the edits, but will not be renamed to edits, since it does not exist in the new image directory. > Name-node should remove edits.new during startup rather than renaming it to > edits. > ---------------------------------------------------------------------------------- > > Key: HADOOP-1978 > URL: https://issues.apache.org/jira/browse/HADOOP-1978 > Project: Hadoop > Issue Type: Bug > Components: dfs > Affects Versions: 0.13.1 > Reporter: Konstantin Shvachko > Assignee: Konstantin Shvachko > Priority: Blocker > Fix For: 0.14.2, 0.15.0 > > Attachments: editsNew-0-15.patch > > > Secondary name-node fails in the middle. The main name-node writes its > journal transactions into edits.new at that time. > If the name-node is shut down after that and restarted, then loadFSImage() > reads current image file, merges it with the edits > file and with the edits.new file. > Now saveFSImage() saves new image file, creates empty edits file, and then > calls rollFSImage(), which particularly renames > edits.new into edits. This is a mistake, during startup edits.new should be > merely removed after merging it with the image. > The purpose of calling rollFSImage() during startups imho is to recover from > an unsuccessful checkpoint. So an easy fix > is to empty edits.new before calling rollFSImage the same as edits are > emptied, then rollFSImage will rename empty file > to empty which gives us the desired result. > We should fix this bug both in 0.14 and 0.15. I make it a blocker for 0.15. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.