apache/hadoop · error · IOException

The layout version {} supports inodeId but gave bogus inodeI

Error message

The layout version {} supports inodeId but gave bogus inodeId

What it means

getAndUpdateLastInodeId validates inode-creating ops: the log's layout version includes ADD_INODE_ID, so inode ids must be serialized, yet the op carried the GRANDFATHER_INODE_ID (0) sentinel reserved for logs too old to contain ids. That combination is self-inconsistent and replay throws IOException. It points at corruption or a faulty log writer, not at a normal upgrade path.

Source

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

        dumpOpCounts(opCounts);
        FSImage.LOG.debug("maxTxnsToRead = " + maxTxnsToRead
            + " actual edits read = " + numEdits);
      }
      assert numEdits <= maxTxnsToRead || numEdits == 1 :
        "should read at least one txn, but not more than the configured max";
    }
    return numEdits;
  }
  
  // allocate and update last allocated inode id
  private long getAndUpdateLastInodeId(long inodeIdFromOp, int logVersion,
      long lastInodeId) throws IOException {
    long inodeId = inodeIdFromOp;

    if (inodeId == HdfsConstants.GRANDFATHER_INODE_ID) {
      if (NameNodeLayoutVersion.supports(
          LayoutVersion.Feature.ADD_INODE_ID, logVersion)) {
        throw new IOException("The layout version " + logVersion
            + " supports inodeId but gave bogus inodeId");
      }
      inodeId = fsNamesys.dir.allocateNewInodeId();
    } else {
      // need to reset lastInodeId. fsnamesys gets lastInodeId firstly from
      // fsimage but editlog captures more recent inodeId allocations
      if (inodeId > lastInodeId) {
        fsNamesys.dir.resetLastInodeId(inodeId);
      }
    }
    return inodeId;
  }

  @SuppressWarnings("deprecation")
  private long applyEditLogOp(FSEditLogOp op, FSDirectory fsDir,
      StartupOption startOpt, int logVersion, long lastInodeId) throws IOException {
    long inodeId = HdfsConstants.GRANDFATHER_INODE_ID;
    if (LOG.isTraceEnabled()) {

View on GitHub (pinned to 2add963021)

Solutions

1. Treat the segment as corrupt: confirm with the OfflineEditsViewer ('hdfs oev -i <segment> -o /tmp/check.xml -p xml')
2. Recover with 'hdfs namenode -recover' and skip the bad section, or restore a matching fsimage plus edits from backup
3. If the logs come from an internal build, fix that writer to allocate and record a real inode id

Example fix

# before: replay aborts with 'gave bogus inodeId'
hdfs --daemon start namenode

# after: prove which segment is bad, then skip it
hdfs oev -i edits_0000000000000001234-0000000000000001400 -o /tmp/check.xml -p xml
hdfs namenode -recover

hdfs oev -i <segment> -o /tmp/check.xml -p xml   # full parse validates every record's fields

try {
  loader.loadFSEdits(storage, 0);
} catch (IOException e) {
  if (e.getMessage() != null && e.getMessage().contains("bogus inodeId")) {
    // structurally corrupt record: restart with 'hdfs namenode -recover'
    // or restore a consistent fsimage+edits pair from backup
  }
  throw e;
}

When it happens

Trigger: Bit-level corruption zeroing the inodeId field of an OP_ADD or similar record; edit logs produced by a patched or buggy build that wrote 0 instead of an allocated id; hand-modified segment files.

Common situations: Disk errors or bad segment transfers; replaying logs from experimental in-house Hadoop builds. Rare on stock releases.

Related errors

• Mismatched block IDs or generation stamps for the old last b
• Mismatched block IDs or generation stamps, attempting to rep
• Trying to remove more than one block from file {}
• Trying to delete non-existant block {}
• Incorrect data format. logVersion is {} but writables.length

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