apache/hadoop · error · ReplicaNotFoundException

Replica does not exist {}:{}

Error message

Replica does not exist {}:{}

What it means

Thrown as ReplicaNotFoundException (NON_EXISTENT_REPLICA prefix) from FsDatasetImpl.getReplicaInfo(String bpid, long blkid), the variant that looks up by block ID without matching generation stamp. If even this coarse lookup misses, the block ID simply has no replica in that block pool. It is also the resolver behind getStorageUuidForLock, so lock acquisition on an unknown block fails here first.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/datanode/fsdataset/impl/FsDatasetImpl.java:918

    }
    return info;
  }

  /**
   * Get the meta info of a block stored in volumeMap. Block is looked up
   * without matching the generation stamp.
   * @param bpid block pool Id
   * @param blkid block Id
   * @return the meta replica information; null if block was not found
   * @throws ReplicaNotFoundException if no entry is in the map or 
   *                        there is a generation stamp mismatch
   */
  @VisibleForTesting
  ReplicaInfo getReplicaInfo(String bpid, long blkid)
      throws ReplicaNotFoundException {
    ReplicaInfo info = volumeMap.get(bpid, blkid);
    if (info == null) {
      throw new ReplicaNotFoundException(
          ReplicaNotFoundException.NON_EXISTENT_REPLICA + bpid + ":" + blkid);
    }
    return info;
  }

  String getStorageUuidForLock(ExtendedBlock b)
      throws ReplicaNotFoundException {
    return getReplicaInfo(b.getBlockPoolId(), b.getBlockId())
        .getStorageUuid();
  }

  /**
   * Returns handles to the block file and its metadata file
   */
  @Override // FsDatasetSpi
  public ReplicaInputStreams getTmpInputStreams(ExtendedBlock b,
      long blkOffset, long metaOffset) throws IOException {
    try (AutoCloseDataSetLock l = lockManager.readLock(LockLevel.DIR,

View on GitHub (pinned to 2add963021)

Solutions

  1. Confirm the block exists on any replica: hdfs fsck <file> -files -blocks -locations for the owning file.
  2. Trigger a block report so NameNode drops this DN from that block's locations (hdfs dfsadmin -triggerBlockReport).
  3. If the DN's dirs were wiped/restored, re-register the block pool (restart DN) instead of trusting stale in-memory maps.
  4. In code, prefer checking replica existence (fsDataset.getReplica(bpid, blkId)) before entering lock-by-block paths.
Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-check by (bpid, blkId) before lock-by-block paths like
// getStorageUuidForLock.
if (fsDataset.getReplica(bpid, blkid) == null) {
  return Optional.empty(); // caller skips instead of throwing
}

Try / catch

try {
  String storageUuid = fsDataset.getStorageUuidForLock(b);
} catch (ReplicaNotFoundException e) {
  // coarse lookup already missed: block unknown in this bp, skip gracefully
  LOG.debug("No replica {}/{}; skipping lock", b.getBlockPoolId(), b.getBlockId());
  return;
}

Prevention

When it happens

Trigger: Calling getReplicaInfo(bpid, blkid) (or APIs that lock by block, e.g. getStorageUuidForLock(ExtendedBlock)) for a block ID absent from volumeMap: invalidated replica, deleted block pool data, post-volume-failure map, or fabricated ID.

Common situations: Directory scanner/block report reconciling stale lists; recoverBlock for a block already deleted on this DN; tests probing unknown IDs; DN serving a block pool whose dirs were wiped but not re-formatted.

Related errors


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