apache/hadoop · error · IOException

Incorrect data format. Old rename operation.

Error message

Incorrect data format. Old rename operation.

What it means

RenameOldOp.readFields() (the pre-options rename record): in legacy layouts without EDITLOG_OP_OPTIMIZATION the record's length word must be exactly 3 (src, dst, timestamp). Any other value means the record is malformed or the stream is misaligned, and the parse fails before reading the paths.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLogOp.java:1457

    }

    @Override
    public 
    void writeFields(DataOutputStream out) throws IOException {
      FSImageSerialization.writeString(src, out);
      FSImageSerialization.writeString(dst, out);
      FSImageSerialization.writeLong(timestamp, out);
      writeRpcIds(rpcClientId, rpcCallId, out);
    }

    @Override
    void readFields(DataInputStream in, int logVersion)
        throws IOException {
      if (!NameNodeLayoutVersion.supports(
          LayoutVersion.Feature.EDITLOG_OP_OPTIMIZATION, logVersion)) {
        this.length = in.readInt();
        if (this.length != 3) {
          throw new IOException("Incorrect data format. "
              + "Old rename operation.");
        }
      }
      this.src = FSImageSerialization.readString(in);
      this.dst = FSImageSerialization.readString(in);
      if (NameNodeLayoutVersion.supports(
          LayoutVersion.Feature.EDITLOG_OP_OPTIMIZATION, logVersion)) {
        this.timestamp = FSImageSerialization.readLong(in);
      } else {
        this.timestamp = readLong(in);
      }
      
      // read RPC ids if necessary
      readRpcIds(in, logVersion);
    }

    @Override
    public String toString() {

View on GitHub (pinned to 2add963021)

Solutions

  1. Run 'hdfs namenode -recover' to skip past the record
  2. Locate the failing txid via 'hdfs offlineEditsViewer' and assess what transaction is lost
  3. Restore the good copy of the segment from QJM majority / SecondaryNameNode, or restart from the last checkpoint
Defensive patterns

Strategy: try-catch

Validate before calling

hdfs offlineEditsViewer -i <legacy edits segment> -o /dev/null

Try / catch

try {
  reader.readOp(); // replaying legacy rename records
} catch (IOException e) {
  // length word != 3: legacy record is corrupt -> recover with 'hdfs namenode -recover'
}

Prevention

When it happens

Trigger: Replaying an old-format edits segment where the length word is corrupt, or where earlier corruption shifted the stream so a body integer is interpreted as the length; also parsing a file that is not an edit log.

Common situations: Old upgrades replaying legacy segments; crash-torn records; damaged name/journal disks.

Related errors


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