Uploaded image for project: 'Hadoop HDFS'
  1. Hadoop HDFS
  2. HDFS-1623 High Availability Framework for HDFS NN
  3. HDFS-2291

HA: Checkpointing in an HA setup

        Details

        • Type: Sub-task
        • Status: Resolved
        • Priority: Major
        • Resolution: Fixed
        • Affects Version/s: HA branch (HDFS-1623)
        • Fix Version/s: HA branch (HDFS-1623)
        • Component/s: ha, namenode
        • Labels:
          None

          Description

          We obviously need to create checkpoints when HA is enabled. One thought is to use a third, dedicated checkpointing node in addition to the active and standby nodes. Another option would be to make the standby capable of also performing the function of checkpointing.

          1. Text File
            hdfs-2291.txt
            67 kB
            Todd Lipcon
          2. Text File
            hdfs-2291.txt
            67 kB
            Todd Lipcon
          3. Text File
            hdfs-2291.txt
            67 kB
            Todd Lipcon
          4. Text File
            hdfs-2291.txt
            44 kB
            Todd Lipcon

            Issue Links

            is blocked by

            Sub-task - The sub-task of the issue HDFS-2716 HA: Configuration needs to allow different dfs.http.addresses for each HA NN

            • Major - Major loss of function.
            • Resolved
            is related to

            Sub-task - The sub-task of the issue HDFS-1973 HA: HDFS clients must handle namenode failover and switch over to the new active namenode.

            • Major - Major loss of function.
            • Resolved

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              umamaheswararao Uma Maheswara Rao G added a comment -

              One thought is to use a third, dedicated checkpointing node in addition to the active and standby nodes.

              Introducing new nodes may create overheads in setting up the clusters. we can always think to reduce the cluster complexities to create setups.

              Another option would be to make the standby capable of also performing the function of checkpointing.

              IMO , standby can do checkpointing job.

              what do you say Aaron?

              Show
              umamaheswararao Uma Maheswara Rao G added a comment - One thought is to use a third, dedicated checkpointing node in addition to the active and standby nodes. Introducing new nodes may create overheads in setting up the clusters. we can always think to reduce the cluster complexities to create setups. Another option would be to make the standby capable of also performing the function of checkpointing. IMO , standby can do checkpointing job. what do you say Aaron?
              Hide
              Permalink
              sureshms Suresh Srinivas added a comment -

              My preference is to do checkpointing in standby. If standby is in the middle checkpointing, it should abandon checkpointing and become active.

              Show
              sureshms Suresh Srinivas added a comment - My preference is to do checkpointing in standby. If standby is in the middle checkpointing, it should abandon checkpointing and become active.
              Hide
              Permalink
              raviprak Ravi Prakash added a comment -

              Will the standby+checkpointing node have to have twice the memory? I thought the main reason for running a secondary namenode on a different machine was because checkpointing needed just as much memory as the namenode needed to maintain metadata.

              Show
              raviprak Ravi Prakash added a comment - Will the standby+checkpointing node have to have twice the memory? I thought the main reason for running a secondary namenode on a different machine was because checkpointing needed just as much memory as the namenode needed to maintain metadata.
              Hide
              Permalink
              sureshms Suresh Srinivas added a comment -

              Will the standby+checkpointing node have to have twice the memory?

              No

              I thought the main reason for running a secondary namenode on a different machine was because checkpointing needed just as much memory as the namenode needed to maintain metadata.

              The reason why we do not do it in primary is, checkpointing blocks the operations.

              Show
              sureshms Suresh Srinivas added a comment - Will the standby+checkpointing node have to have twice the memory? No I thought the main reason for running a secondary namenode on a different machine was because checkpointing needed just as much memory as the namenode needed to maintain metadata. The reason why we do not do it in primary is, checkpointing blocks the operations.
              Hide
              Permalink
              raviprak Ravi Prakash added a comment -

              @Suresh: Thanks! Blame not the dev for what he read in docs outdated http://hadoop.apache.org/common/docs/current/hdfs_user_guide.html#Secondary+NameNode

              It is usually run on a different machine than the primary NameNode since its memory requirements are on the same order as the primary NameNode

              Show
              raviprak Ravi Prakash added a comment - @Suresh: Thanks! Blame not the dev for what he read in docs outdated http://hadoop.apache.org/common/docs/current/hdfs_user_guide.html#Secondary+NameNode It is usually run on a different machine than the primary NameNode since its memory requirements are on the same order as the primary NameNode
              Hide
              Permalink
              tlipcon Todd Lipcon added a comment -

              Ravi: the docs are right – the 2NN needs as much memory as the NN. But the same is true of the SBN. But it's the same memory - a copy of the namespace, etc.

              So, I agree that the SBN should be able to do checkpoints. We just need to implement a "checkpoint abort" functionality. I will look into this.

              Show
              tlipcon Todd Lipcon added a comment - Ravi: the docs are right – the 2NN needs as much memory as the NN. But the same is true of the SBN. But it's the same memory - a copy of the namespace, etc. So, I agree that the SBN should be able to do checkpoints. We just need to implement a "checkpoint abort" functionality. I will look into this.
              Hide
              Permalink
              eli Eli Collins added a comment -

              Agree that the SBN should be able to do checkpoints - someone running a typical 20x configuration with two hosts (NN and 2NN) should be able to keep the same hardware config (NN and SBN).

              Show
              eli Eli Collins added a comment - Agree that the SBN should be able to do checkpoints - someone running a typical 20x configuration with two hosts (NN and 2NN) should be able to keep the same hardware config (NN and SBN).
              Hide
              Permalink
              tlipcon Todd Lipcon added a comment -

              I plan to start working on this tomorrow. My thinking is to have a checkpoint thread which wakes up on the checkpoint interval, stops the edit log tailer thread, enters safe mode, creates a checkpoint, and comes back out of safemode. If at any point the SB needs to process a failover, it will cancel the checkpoint (using the HDFS-2507 feature) and proceed as usual.

              The remaining question I've yet to figure out is whether it should (a) save the checkpoints into the shared edits directory, or (b) save in its own and then upload the checkpoints to the primary via HTTP just like the 2NN does today.

              "b" is probably preferable since the shared edits directory may in fact be BK or some other journal plugin in the future, whereas "a" would break the abstraction.

              If anyone has any strong opinions please shout now

              Show
              tlipcon Todd Lipcon added a comment - I plan to start working on this tomorrow. My thinking is to have a checkpoint thread which wakes up on the checkpoint interval, stops the edit log tailer thread, enters safe mode, creates a checkpoint, and comes back out of safemode. If at any point the SB needs to process a failover, it will cancel the checkpoint (using the HDFS-2507 feature) and proceed as usual. The remaining question I've yet to figure out is whether it should (a) save the checkpoints into the shared edits directory, or (b) save in its own and then upload the checkpoints to the primary via HTTP just like the 2NN does today. "b" is probably preferable since the shared edits directory may in fact be BK or some other journal plugin in the future, whereas "a" would break the abstraction. If anyone has any strong opinions please shout now
              Hide
              Permalink
              atm Aaron T. Myers added a comment -

              I support option "b," not only for the reason stated above. Option "b" also implicitly solves the problem of what to do about fsimages in the standby, as well as just seeming overall safer. I'm leery of any plan which involves the standby temporarily writing to the shared edits dir.

              Show
              atm Aaron T. Myers added a comment - I support option "b," not only for the reason stated above. Option "b" also implicitly solves the problem of what to do about fsimages in the standby, as well as just seeming overall safer. I'm leery of any plan which involves the standby temporarily writing to the shared edits dir.
              Hide
              Permalink
              eli Eli Collins added a comment -

              Ditto, option (b) seems preferable. I think we should minimize the difference between the 2NN and the SBN checkpointing since we'll have to support both.

              Show
              eli Eli Collins added a comment - Ditto, option (b) seems preferable. I think we should minimize the difference between the 2NN and the SBN checkpointing since we'll have to support both.
              Hide
              Permalink
              tlipcon Todd Lipcon added a comment -

              Attached patch adds a thread to the SBN which takes checkpoints.

              It doesn't currently deal with the case where a checkpoint is happening while the SBN needs to become active. I'm working on that now, but figured I'd put this patch up for early review.

              This depends on HDFS-2716.

              Show
              tlipcon Todd Lipcon added a comment - Attached patch adds a thread to the SBN which takes checkpoints. It doesn't currently deal with the case where a checkpoint is happening while the SBN needs to become active. I'm working on that now, but figured I'd put this patch up for early review. This depends on HDFS-2716 .
              Hide
              Permalink
              tlipcon Todd Lipcon added a comment -

              New iteration of the patch handles canceling checkpoints if a failover happens in the middle of the process.

              There is still one very narrow race where the cancellation doesn't work – but it won't cause a crash or anything, just a delayed failover. I'd like to address that in a followup since it wasn't simple to fix.

              I took the liberty of refactoring some common configuration code out into a new CheckpointConf class.. hope that's OK.

              I'll probably upload one more rev of this patch with better comments/javadoc, but this should be ready for general review.

              Show
              tlipcon Todd Lipcon added a comment - New iteration of the patch handles canceling checkpoints if a failover happens in the middle of the process. There is still one very narrow race where the cancellation doesn't work – but it won't cause a crash or anything, just a delayed failover. I'd like to address that in a followup since it wasn't simple to fix. I took the liberty of refactoring some common configuration code out into a new CheckpointConf class.. hope that's OK. I'll probably upload one more rev of this patch with better comments/javadoc, but this should be ready for general review.
              Hide
              Permalink
              atm Aaron T. Myers added a comment -

              Thanks a lot for providing this patch, Todd. What's below are mostly nits. I agree that there could be a few more comments for the new public methods, so I didn't include that in my feedback.

              1. dfs.namenode.standby.checkpoints - perhaps include ".ha" in there to make it clear that this option is only applicable in an HA setup?
              2. Might as well make the members of CheckpointConf final.
              3. LOG.info("Counted txns in " + file + ": " + val.getNumTransactions()); - Either should be removed or should not be info level.
              4. prepareStopStandbyServices is kind of a weird name. Perhaps "prepareToStopStandbyServices" ?
              5. "// TODO interface audience" in TransferFsImage
              6. Does it not seem strange to you that the order of operations when setting a state is "prepareExit -> prepareEnter -> exit -> enter," instead of "prepareExit -> exit -> prepareEnter -> enter" ? i.e. I don't think there's a correctness issue here, but if I were designing a system where this set of events is triggered, I'd go with the latter.
              7. What's the point of the changes in EditLogTailer?
              8. "TODO: need to cancel the savenamespace operation if it's in flight" - I think this comment is no longer applicable to this patch, right?
              9. LOG.info("Time for a checkpoint !"); - while strictly accurate, this doesn't seem to be the most helpful log message.
              10. Can we make CheckpointerThread a static inner class?
              11. e.printStackTrace(); in CheckpointerThread should probably be tossed.
              12. Nit: in CheckpointerThread#doWork: "if(UserGroupInformation.isSecurityEnabled())" - space between "if" and "(", and curly braces around body of "if".
              13. You use "System.currentTimeMillis" in a bunch of places. How about replacing with "o.a.h.hdfs.server.common.Util#now" ?
              14. Does it make sense to explicitly disallow the SBN from allowing checkpoints to be uploaded to it? I realize the case when both nodes are in standby is already handled by this patch, since you don't allow checkpoints if the node already has a checkpoint for a given txid, but I mean from a principled perspective. It seems kind of odd to me that two nodes both sitting in standby would be doing checkpoint transfers at all.
              Show
              atm Aaron T. Myers added a comment - Thanks a lot for providing this patch, Todd. What's below are mostly nits. I agree that there could be a few more comments for the new public methods, so I didn't include that in my feedback. dfs.namenode.standby.checkpoints - perhaps include ".ha" in there to make it clear that this option is only applicable in an HA setup? Might as well make the members of CheckpointConf final. LOG.info("Counted txns in " + file + ": " + val.getNumTransactions()); - Either should be removed or should not be info level. prepareStopStandbyServices is kind of a weird name. Perhaps "prepareToStopStandbyServices" ? "// TODO interface audience" in TransferFsImage Does it not seem strange to you that the order of operations when setting a state is "prepareExit -> prepareEnter -> exit -> enter," instead of "prepareExit -> exit -> prepareEnter -> enter" ? i.e. I don't think there's a correctness issue here, but if I were designing a system where this set of events is triggered, I'd go with the latter. What's the point of the changes in EditLogTailer ? "TODO: need to cancel the savenamespace operation if it's in flight" - I think this comment is no longer applicable to this patch, right? LOG.info("Time for a checkpoint !"); - while strictly accurate, this doesn't seem to be the most helpful log message. Can we make CheckpointerThread a static inner class? e.printStackTrace(); in CheckpointerThread should probably be tossed. Nit: in CheckpointerThread#doWork : "if(UserGroupInformation.isSecurityEnabled())" - space between "if" and "(", and curly braces around body of "if". You use "System.currentTimeMillis" in a bunch of places. How about replacing with "o.a.h.hdfs.server.common.Util#now" ? Does it make sense to explicitly disallow the SBN from allowing checkpoints to be uploaded to it? I realize the case when both nodes are in standby is already handled by this patch, since you don't allow checkpoints if the node already has a checkpoint for a given txid, but I mean from a principled perspective. It seems kind of odd to me that two nodes both sitting in standby would be doing checkpoint transfers at all.
              Hide
              Permalink
              tlipcon Todd Lipcon added a comment -

              dfs.namenode.standby.checkpoints - perhaps include ".ha" in there to make it clear that this option is only applicable in an HA setup

              renamed to dfs.ha.standby.checkpoints and DFS_HA_STANDBY_CHECKPOINTS_KEY

              Might as well make the members of CheckpointConf final.

              LOG.info("Counted txns in " + file + ": " + val.getNumTransactions()); - Either should be removed or should not be info level.

              prepareStopStandbyServices is kind of a weird name. Perhaps "prepareToStopStandbyServices" ?

              "// TODO interface audience" in TransferFsImage

              "TODO: need to cancel the savenamespace operation if it's in flight" - I think this comment is no longer applicable to this patch, right?

              LOG.info("Time for a checkpoint !"); - while strictly accurate, this doesn't seem to be the most helpful log message.

              e.printStackTrace(); in CheckpointerThread should probably be tossed.

              Nit: in CheckpointerThread#doWork: "if(UserGroupInformation.isSecurityEnabled())" - space between "if" and "(", and curly braces around body of "if".

              You use "System.currentTimeMillis" in a bunch of places. How about replacing with "o.a.h.hdfs.server.common.Util#now" ?

              fixed the above

              Does it not seem strange to you that the order of operations when setting a state is "prepareExit -> prepareEnter -> exit -> enter," instead of "prepareExit -> exit -> prepareEnter -> enter

              The point of the prepare* methods is that they have to happen before the lock is taken. So, prepareEnter can't happen after exit, because the lock already is held there. I clarified the javadoc a bit.

              What's the point of the changes in EditLogTailer?

              In order for the test to spy on saveNamespace, I had to move the getFSImage call down. Otherwise, the spy wasn't getting picked up properly and the test was failing.

              Can we make CheckpointerThread a static inner class?

              Currently it calls doCheckpoint in the outer class. I suppose it could be static, but it isn't really easy to test in isolation anyway, so I'm going to punt o this.

              Does it make sense to explicitly disallow the SBN from allowing checkpoints to be uploaded to it?

              Yes and no... I sort of see your point. But, people have also discussed an external tool which would perform checkpoints for many clusters and then upload them

              Show
              tlipcon Todd Lipcon added a comment - dfs.namenode.standby.checkpoints - perhaps include ".ha" in there to make it clear that this option is only applicable in an HA setup renamed to dfs.ha.standby.checkpoints and DFS_HA_STANDBY_CHECKPOINTS_KEY Might as well make the members of CheckpointConf final. LOG.info("Counted txns in " + file + ": " + val.getNumTransactions()); - Either should be removed or should not be info level. prepareStopStandbyServices is kind of a weird name. Perhaps "prepareToStopStandbyServices" ? "// TODO interface audience" in TransferFsImage "TODO: need to cancel the savenamespace operation if it's in flight" - I think this comment is no longer applicable to this patch, right? LOG.info("Time for a checkpoint !"); - while strictly accurate, this doesn't seem to be the most helpful log message. e.printStackTrace(); in CheckpointerThread should probably be tossed. Nit: in CheckpointerThread#doWork: "if(UserGroupInformation.isSecurityEnabled())" - space between "if" and "(", and curly braces around body of "if". You use "System.currentTimeMillis" in a bunch of places. How about replacing with "o.a.h.hdfs.server.common.Util#now" ? fixed the above Does it not seem strange to you that the order of operations when setting a state is "prepareExit -> prepareEnter -> exit -> enter," instead of "prepareExit -> exit -> prepareEnter -> enter The point of the prepare* methods is that they have to happen before the lock is taken. So, prepareEnter can't happen after exit , because the lock already is held there. I clarified the javadoc a bit. What's the point of the changes in EditLogTailer? In order for the test to spy on saveNamespace, I had to move the getFSImage call down. Otherwise, the spy wasn't getting picked up properly and the test was failing. Can we make CheckpointerThread a static inner class? Currently it calls doCheckpoint in the outer class. I suppose it could be static, but it isn't really easy to test in isolation anyway, so I'm going to punt o this. Does it make sense to explicitly disallow the SBN from allowing checkpoints to be uploaded to it? Yes and no... I sort of see your point. But, people have also discussed an external tool which would perform checkpoints for many clusters and then upload them
              Hide
              Permalink
              tlipcon Todd Lipcon added a comment -

              Updated patch attached

              Show
              tlipcon Todd Lipcon added a comment - Updated patch attached
              Hide
              Permalink
              atm Aaron T. Myers added a comment -

              Yes and no... I sort of see your point. But, people have also discussed an external tool which would perform checkpoints for many clusters and then upload them

              I'm still a little leery of this behavior, but I don't feel strongly about it, so let's just roll with it.

              I should have said this earlier, but I'd also recommend changing "prepareEnterState" to "prepareToEnterState", and likewise for exit.

              Otherwise the patch looks good to me. +1 once that's addressed.

              Show
              atm Aaron T. Myers added a comment - Yes and no... I sort of see your point. But, people have also discussed an external tool which would perform checkpoints for many clusters and then upload them I'm still a little leery of this behavior, but I don't feel strongly about it, so let's just roll with it. I should have said this earlier, but I'd also recommend changing "prepareEnterState" to "prepareToEnterState", and likewise for exit. Otherwise the patch looks good to me. +1 once that's addressed.
              Hide
              Permalink
              tlipcon Todd Lipcon added a comment -

              Updated patch with that last rename. I'll commit this momentarily. Thanks for the detailed review.

              Show
              tlipcon Todd Lipcon added a comment - Updated patch with that last rename. I'll commit this momentarily. Thanks for the detailed review.
              Hide
              Permalink
              tlipcon Todd Lipcon added a comment -

              Committed to HA branch

              Show
              tlipcon Todd Lipcon added a comment - Committed to HA branch
              Hide
              Permalink
              hudson Hudson added a comment -

              Integrated in Hadoop-Hdfs-HAbranch-build #38 (See https://builds.apache.org/job/Hadoop-Hdfs-HAbranch-build/38/)
              HDFS-2291. Allow the StandbyNode to make checkpoints in an HA setup. Contributed by Todd Lipcon.

              todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1227411
              Files :

              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/CHANGES.HDFS-1623.txt
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSConfigKeys.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/CheckpointConf.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/Checkpointer.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLog.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSImage.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/GetImageServlet.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NNStorage.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNode.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/SaveNamespaceCancelledException.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/SecondaryNameNode.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/TransferFsImage.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/ha/EditLogTailer.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/ha/HAContext.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/ha/HAState.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/ha/StandbyCheckpointer.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/ha/StandbyState.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/MiniDFSCluster.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/MiniDFSNNTopology.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/FSImageTestUtil.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/NameNodeAdapter.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestCheckpoint.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/ha/TestEditLogsDuringFailover.java
              • /hadoop/common/branches/HDFS-1623/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/ha/TestStandbyCheckpoints.java
              Show
              hudson Hudson added a comment - Integrated in Hadoop-Hdfs-HAbranch-build #38 (See https://builds.apache.org/job/Hadoop-Hdfs-HAbranch-build/38/ ) HDFS-2291 . Allow the StandbyNode to make checkpoints in an HA setup. Contributed by Todd Lipcon. todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1227411 Files : /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/CHANGES. HDFS-1623 .txt /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSConfigKeys.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/CheckpointConf.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/Checkpointer.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLog.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSImage.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/GetImageServlet.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NNStorage.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNode.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/SaveNamespaceCancelledException.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/SecondaryNameNode.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/TransferFsImage.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/ha/EditLogTailer.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/ha/HAContext.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/ha/HAState.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/ha/StandbyCheckpointer.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/ha/StandbyState.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/MiniDFSCluster.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/MiniDFSNNTopology.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/FSImageTestUtil.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/NameNodeAdapter.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestCheckpoint.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/ha/TestEditLogsDuringFailover.java /hadoop/common/branches/ HDFS-1623 /hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/ha/TestStandbyCheckpoints.java

                People

                • Assignee:
                  tlipcon Todd Lipcon
                  Reporter:
                  atm Aaron T. Myers
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  12 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Development