Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Major 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. hdfs-2291.txt
        44 kB
        Todd Lipcon
      2. hdfs-2291.txt
        67 kB
        Todd Lipcon
      3. hdfs-2291.txt
        67 kB
        Todd Lipcon
      4. hdfs-2291.txt
        67 kB
        Todd Lipcon

        Issue Links

          Activity

          Hide
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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 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
          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
          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
          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
          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
          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 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
          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
          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
          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
          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
          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
          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
          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
          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
          Todd Lipcon added a comment -

          Updated patch attached

          Show
          Todd Lipcon added a comment - Updated patch attached
          Hide
          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
          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
          Todd Lipcon added a comment -

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

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

          Committed to HA branch

          Show
          Todd Lipcon added a comment - Committed to HA branch
          Hide
          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 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:
              Todd Lipcon
              Reporter:
              Aaron T. Myers
            • Votes:
              0 Vote for this issue
              Watchers:
              13 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development