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 FsVolumeSpiView on GitHub (pinned to 2add963021)
Solutions
- Check current execution state first: 'hdfs diskbalancer -query <datanode>' shows PLAN_UNDER_PROGRESS with the running planID
- 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
- Wait for the running plan to finish if it is doing useful work - query again until status leaves PLAN_UNDER_PROGRESS
- 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
- Always run 'hdfs diskbalancer -query <node>' before -execute; treat IN_PROGRESS as a hard stop
- Set an explicit bandwidth for disk balancer so plans complete in a known window and reduce re-submit temptation
- Wrap operational scripts with a query-cancel-execute sequence instead of bare execute
- Remember 'force' only skips plan validations, never the single-plan-at-a-time rule
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
- NO_SUCH_PLAN
- DISK_BALANCER_NOT_ENABLED
- Another {name} is running.
- Commit or complete block {commitBlock}, whereas it is under
- Interrupted while running disk check
AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22).
Data as JSON: /api/errors/f2789c6fd5d2157b.
Report an issue: GitHub.