[HDFS-7645] Rolling upgrade is restoring blocks from trash multiple times

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.6.0
• Fix Version/s: 2.8.0, 2.7.2, 3.0.0-alpha1
• Component/s: datanode
• Hadoop Flags: Reviewed
• Assignee: Keisuke Ogiwara
• Reporter: Nathan Roberts
• Created: 20/Jan/15 21:12
• Updated: 01/Dec/16 23:26
• Resolved: 30/Mar/15 22:27

Description

When performing an HDFS rolling upgrade, the trash directory is getting restored twice when under normal circumstances it shouldn't need to be restored at all. iiuc, the only time these blocks should be restored is if we need to rollback a rolling upgrade.

On a busy cluster, this can cause significant and unnecessary block churn both on the datanodes, and more importantly in the namenode.

The two times this happens are:
1) restart of DN onto new software

  private void doTransition(DataNode datanode, StorageDirectory sd,
      NamespaceInfo nsInfo, StartupOption startOpt) throws IOException {
    if (startOpt == StartupOption.ROLLBACK && sd.getPreviousDir().exists()) {
      Preconditions.checkState(!getTrashRootDir(sd).exists(),
          sd.getPreviousDir() + " and " + getTrashRootDir(sd) + " should not " +
          " both be present.");
      doRollback(sd, nsInfo); // rollback if applicable
    } else {
      // Restore all the files in the trash. The restored files are retained
      // during rolling upgrade rollback. They are deleted during rolling
      // upgrade downgrade.
      int restored = restoreBlockFilesFromTrash(getTrashRootDir(sd));
      LOG.info("Restored " + restored + " block files from trash.");
    }

2) When heartbeat response no longer indicates a rollingupgrade is in progress

  /**
   * Signal the current rolling upgrade status as indicated by the NN.
   * @param inProgress true if a rolling upgrade is in progress
   */
  void signalRollingUpgrade(boolean inProgress) throws IOException {
    String bpid = getBlockPoolId();
    if (inProgress) {
      dn.getFSDataset().enableTrash(bpid);
      dn.getFSDataset().setRollingUpgradeMarker(bpid);
    } else {
      dn.getFSDataset().restoreTrash(bpid);
      dn.getFSDataset().clearRollingUpgradeMarker(bpid);
    }
  }

HDFS-6800 and HDFS-6981 were modifying this behavior making it not completely clear whether this is somehow intentional.

Issue Links

• breaks: HDFS-9426 Rollingupgrade finalization is not backward compatible
• is depended upon by: HDFS-8676 Delayed rolling upgrade finalization can cause heartbeat expiration and write failures
• is related to: HDFS-8656 Preserve compatibility of ClientProtocol#rollingUpgrade after finalization
• relates to: HDFS-7842 Blocks missed while performing downgrade immediately after rolling back the cluster.