apache/hadoop · error · UnsupportedOperationException

ProvidedReplica does not yet support writes

Error message

ProvidedReplica does not yet support writes

What it means

bumpReplicaGS(long) rewrites a replica's generation stamp on disk when a block is recovered or updated for a new writer. ProvidedReplica throws UnsupportedOperationException ('does not yet support writes') because the remote bytes, and hence their generation stamp, are fixed in the provided store.

Source

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

  public boolean renameData(URI destURI) throws IOException {
    throw new UnsupportedOperationException(
        "ProvidedReplica does not support renaming data");
  }

  @Override
  public boolean getPinning(LocalFileSystem localFS) throws IOException {
    return false;
  }

  @Override
  public void setPinning(LocalFileSystem localFS) throws IOException {
    throw new UnsupportedOperationException(
        "ProvidedReplica does not support pinning");
  }

  @Override
  public void bumpReplicaGS(long newGS) throws IOException {
    throw new UnsupportedOperationException(
        "ProvidedReplica does not yet support writes");
  }

  @Override
  public boolean breakHardLinksIfNeeded() throws IOException {
    return false;
  }

  @Override
  public ReplicaRecoveryInfo createInfo()
      throws UnsupportedOperationException {
    throw new UnsupportedOperationException(
        "ProvidedReplica does not yet support writes");
  }

  @Override
  public int compareWith(ScanInfo info) {
    if (info.getFileRegion().equals(

View on GitHub (pinned to 2add963021)

Solutions

1. Keep append/overwrite/recovery workloads off provided-storage namespaces; provided replicas are read-only references.
2. Pre-check the replica/volume type (instanceof ProvidedReplica or ProvidedVolume) before bumpReplicaGS and reject the write with a clear NameNode-level error.
3. Copy data to local storage if a provided block truly must be re-opened for writes, then operate on the local copy.
4. Catch UnsupportedOperationException at the write-path boundary and fail the operation cleanly rather than crashing the DataNode thread.

Example fix

// before
replica.bumpReplicaGS(newGS);

// after
if (replica instanceof ProvidedReplica) {
  throw new IOException("Cannot bump GS of read-only PROVIDED replica " + replica.getBlockId());
}
replica.bumpReplicaGS(newGS);

if (replica instanceof ProvidedReplica) {
  throw new IOException("Cannot bump GS of read-only PROVIDED replica "
      + replica.getBlockId());
}
replica.bumpReplicaGS(newGS);

static boolean isProvided(ReplicaInfo r) {
  return r instanceof ProvidedReplica;
}

try {
  replica.bumpReplicaGS(newGS);
} catch (UnsupportedOperationException e) {
  throw new IOException("PROVIDED replica " + replica.getBlockId()
      + " does not support writes (bump GS)", e);
}

When it happens

Trigger: Block recovery (DataNode syncBlock) or updateBlock/updateReplica paths that call bumpReplicaGS on a replica which turns out to be a ProvidedReplica - i.e. a lease-recovery, append, or truncate-recovery attempt on a file backed by provided storage.

Common situations: A client opens an existing provided-storage file for append (or triggers lease recovery on it) while the DataNode serves that block from a PROVIDED volume; the write-path code assumes a mutable local replica.

Related errors

• Replica gen stamp < block genstamp, block={block}, replica={
• The new recovery id: {} must be greater than the current one
• Cannot append to a replica with unexpected generation stamp
• Cannot append to a replica with unexpected generation stamp
• replica.getGenerationStamp() < block.getGenerationStamp(), b

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