apache/hadoop · error · IOException

Block pool IDs mismatched: block${i}=${blocki}, expected blo

Error message

Block pool IDs mismatched: block${i}=${blocki}, expected block group=${blockGroup}

What it means

StripedBlockUtil.checkBlocks() validates that an internal block i of a striped block group matches the group. This first check requires the block pool ID of block i to equal the group's block pool ID; a mismatch throws IOException. It is called from DFSStripedOutputStream.waitEndBlocks() while writing an erasure-coded file, when each streamer reports its allocated block before a new block group starts — so the error fails the EC file write.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs-client/src/main/java/org/apache/hadoop/hdfs/util/StripedBlockUtil.java:1010

    public long getLength() {
      return length;
    }

    @Override
    public String toString() {
      return String.format("StripeRange(offsetInBlock=%d, length=%d)",
          offsetInBlock, length);
    }
  }

  /**
   * Check if the information such as IDs and generation stamps in block-i
   * match the block group.
   */
  public static void checkBlocks(ExtendedBlock blockGroup,
      int i, ExtendedBlock blocki) throws IOException {
    if (!blocki.getBlockPoolId().equals(blockGroup.getBlockPoolId())) {
      throw new IOException("Block pool IDs mismatched: block" + i + "="
          + blocki + ", expected block group=" + blockGroup);
    }
    if (blocki.getBlockId() - i != blockGroup.getBlockId()) {
      throw new IOException("Block IDs mismatched: block" + i + "="
          + blocki + ", expected block group=" + blockGroup);
    }
    if (blocki.getGenerationStamp() != blockGroup.getGenerationStamp()) {
      throw new IOException("Generation stamps mismatched: block" + i + "="
          + blocki + ", expected block group=" + blockGroup);
    }
  }

  public static int getBlockIndex(Block reportedBlock) {
    long BLOCK_GROUP_INDEX_MASK = 15;
    return (int) (reportedBlock.getBlockId() &
        BLOCK_GROUP_INDEX_MASK);
  }
}

View on GitHub (pinned to 2add963021)

Solutions

Retry the write job — transient allocation races during DN restart/decommission usually clear
Verify all NameNodes and DataNodes run the same (compatible) Hadoop version; EC block-group layout changed across releases
Inspect the block pool IDs in the message: if they name different namespaces, check federation/nameservice routing for the client
If reproducible, collect NN and DN logs for the block ids in the message and open a Hadoop JIRA

Defensive patterns

Strategy: try-catch

Try / catch

try {
  try (FSDataOutputStream out = fs.create(ecPath)) { /* write striped data */ }
} catch (IOException e) {
  if (e.getMessage() != null && e.getMessage().contains("Block pool IDs mismatched")) {
    // internal allocation inconsistency: retry the job once, then investigate cluster health
    LOG.warn("Striped write failed on block pool mismatch, retrying", e);
  } else { throw e; }
}

Prevention

Keep NN/DN versions uniform across the cluster during EC writes
Avoid starting EC writes during rolling upgrades or mass DN restarts
Retain the block pool IDs from the message for cluster forensics

When it happens

Trigger: Writing an EC (striped) file when an internal block handed back by a datanode belongs to a different block pool than the block group — effectively cross-namespace block assignment; in practice only from internal inconsistency or a defect, not from client configuration.

Common situations: Cluster upgrades where NN/DN disagree on block group layout, federated namespaces misrouting allocations, or Hadoop bug reports around striped block allocation. Users see it as a failed write of an erasure-coded file.

Related errors

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