apache/hadoop · critical · IOException

Edits file is not found in {}

Error message

Edits file is not found in {}

What it means

Companion check in FSImagePreTransactionalStorageInspector.getLatestImages() for legacy pre-transactional layouts: after inspecting all configured edits directories, latestEditsSD is still null, i.e. no storage directory supplied an edits log. The inspector needs both an image and an edits file to compute the namespace state, so startup aborts.

Source

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

      } finally {
        IOUtils.cleanupWithLogger(LOG, in);
      }
    }
    return timeStamp;
  }

  @Override
  boolean isUpgradeFinalized() {
    return isUpgradeFinalized;
  }
    
  @Override
  List<FSImageFile> getLatestImages() throws IOException {
    // We should have at least one image and one edits dirs
    if (latestNameSD == null)
      throw new IOException("Image file is not found in " + imageDirs);
    if (latestEditsSD == null)
      throw new IOException("Edits file is not found in " + editsDirs);
    
    // Make sure we are loading image and edits from same checkpoint
    if (latestNameCheckpointTime > latestEditsCheckpointTime
        && latestNameSD != latestEditsSD
        && latestNameSD.getStorageDirType() == NameNodeDirType.IMAGE
        && latestEditsSD.getStorageDirType() == NameNodeDirType.EDITS) {
      // This is a rare failure when NN has image-only and edits-only
      // storage directories, and fails right after saving images,
      // in some of the storage directories, but before purging edits.
      // See -NOTE- in saveNamespace().
      LOG.error("This is a rare failure scenario!!!");
      LOG.error("Image checkpoint time " + latestNameCheckpointTime +
                " > edits checkpoint time " + latestEditsCheckpointTime);
      LOG.error("Name-node will treat the image as the latest state of " +
                "the namespace. Old edits will be discarded.");
    } else if (latestNameCheckpointTime != latestEditsCheckpointTime) {
      throw new IOException("Inconsistent storage detected, " +
                      "image and edits checkpoint times do not match. " +

View on GitHub (pinned to 2add963021)

Solutions

  1. List the edits files present in each directory of dfs.namenode.edits.dir and confirm they are readable
  2. Restore the edits file from backup or another storage directory copy
  3. Fix dfs.namenode.edits.dir to point at the directories that actually hold the journal, then restart
  4. If only an fsimage survives, recover the namespace from that image (accepting loss of post-checkpoint operations) or re-import a SecondaryNameNode checkpoint

Example fix

# before: no edits file anywhere under the edits dirs
ls /dfs/edits/current/   # only fstime, no edits
# after: restore the journal that matches the image checkpoint
cp /backup/edits /dfs/edits/current/
Defensive patterns

Strategy: validation

Validate before calling

for (URI u : FSNamesystem.getEditsDirs(conf)) {
  File f = new File(u.getPath(), "current/edits");
  if (!f.exists()) {
    LOG.error("no edits file in " + f);
  }
}

Try / catch

catch IOException from FSImage#loadFSImage; the exception prints the scanned editsDirs — verify each listed directory actually contains an edits file before retrying.

Prevention

When it happens

Trigger: Booting a NameNode on pre-transactional-format storage where no dfs.namenode.edits.dir directory contains an edits file: IMAGE-only formatted dirs, edits file deleted, or edits dirs pointing at empty/wrong paths.

Common situations: Storage directories configured as IMAGE-only (NameNodeDirType.IMAGE) so no edits exist anywhere; edits removed during cleanup; wrong edits.dir after re-mounting storage.

Related errors

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