apache/hadoop · error · DiskBalancerException

PLAN_ALREADY_IN_PROGRESS

PLAN_ALREADY_IN_PROGRESS

Error message

Executing another plan

What it means

DiskBalancerException with Result.PLAN_ALREADY_IN_PROGRESS from DiskBalancer.submitPlan: a disk-balancer plan file is being submitted for execution while a previously submitted plan on this DataNode is still running (this.future != null && !this.future.isDone()). The DataNode executes at most one plan at a time under its lock; note that the 'force' flag skips plan validations but NOT this in-progress check.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/datanode/DiskBalancer.java:189

   * can be executed by the blockMover.
   *
   * @param planId      - A SHA-1 of the plan string
   * @param planVersion - version of the plan string - for future use.
   * @param planFileName    - Plan file name
   * @param planData    - Plan data in json format
   * @param force       - Skip some validations and execute the plan file.
   * @throws DiskBalancerException
   */
  public void submitPlan(String planId, long planVersion, String planFileName,
                         String planData, boolean force)
          throws DiskBalancerException {
    lock.lock();
    try {
      checkDiskBalancerEnabled();
      if ((this.future != null) && (!this.future.isDone())) {
        LOG.error("Disk Balancer - Executing another plan (Plan File: {}, Plan ID: {}), " +
            "submitPlan failed.", planFile, planID);
        throw new DiskBalancerException("Executing another plan",
            DiskBalancerException.Result.PLAN_ALREADY_IN_PROGRESS);
      }
      NodePlan nodePlan = verifyPlan(planId, planVersion, planData, force);
      createWorkPlan(nodePlan);
      this.planID = planId;
      this.planFile = planFileName;
      this.currentResult = Result.PLAN_UNDER_PROGRESS;
      executePlan();
    } finally {
      lock.unlock();
    }
  }

  /**
   * Get FsVolume by volume UUID.
   * @param fsDataset
   * @param volUuid
   * @return FsVolumeSpi

View on GitHub (pinned to 2add963021)

Solutions

  1. Check current execution state first: 'hdfs diskbalancer -query <datanode>' shows PLAN_UNDER_PROGRESS with the running planID
  2. Cancel the running plan, then submit the new one: 'hdfs diskbalancer -cancel <runningPlanID>' (or -cancel planID with the node) and wait for it to stop before -execute
  3. Wait for the running plan to finish if it is doing useful work - query again until status leaves PLAN_UNDER_PROGRESS
  4. Set an explicit bandwidth ('hdfs diskbalancer -bandwidth' / dfs.disk.balancer.max.disk.throughput) so plans finish in a predictable window instead of being re-submitted

Example fix

# before: second execute while plan still running -> PLAN_ALREADY_IN_PROGRESS
hdfs diskbalancer -execute /system/diskbalancer/<node>-plan.json
hdfs diskbalancer -execute /system/diskbalancer/<node>-plan-v2.json

# after: query, cancel running plan, then execute the new one
hdfs diskbalancer -query <datanode>:<ipc_port>          # note running PlanID
hdfs diskbalancer -cancel <runningPlanID>
hdfs diskbalancer -execute /system/diskbalancer/<node>-plan-v2.json
Defensive patterns

Strategy: validation

Validate before calling

// CLI flow: check plan status before executing a new one
//   hdfs diskbalancer -query <datanode>  -> read PlanStatus / PlanID
// API sketch:
DiskBalancerResult status = diskBalancer.getPlanStatus();
if (status.getResult() == Result.PLAN_UNDER_PROGRESS) {
  diskBalancer.cancelPlan(status.getPlanID());   // or wait/await completion
  waitForPlanDone(status.getPlanID());
}
diskBalancer.submitPlan(planId, planVersion, planFile, planData, force);

Try / catch

try {
  diskBalancer.submitPlan(planId, version, planFile, planData, force);
} catch (DiskBalancerException e) {
  if (e.getResult() == DiskBalancerException.Result.PLAN_ALREADY_IN_PROGRESS) {
    // query the running plan; cancel it deliberately, then resubmit -
    // the force flag does NOT bypass this check
  }
}

Prevention

When it happens

Trigger: Running 'hdfs diskbalancer -execute <planfile>' on a node twice, or executing a second plan while the first (which can run for hours at the configured bandwidth) is still copying data between volumes.

Common situations: Operators re-running execute because the first invocation 'seemed hung' (slow bandwidth throttling); automation scripts re-submitting on timeout; iterating on plans without checking current status.

Related errors


AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/f2789c6fd5d2157b. Report an issue: GitHub.