apache/hadoop · error · IOException

Cannot process fslayout version {imageVersion}

Error message

Cannot process fslayout version {imageVersion}

What it means

ImageLoaderCurrent is the legacy (pre-protobuf) fsimage reader behind `hdfs oiv_legacy`. loadImage reads the first int of the image and calls canLoadVersion, which accepts exactly the layout versions listed in the array at ImageLoaderCurrent.java:129-131 (-16 through -51). Any other value - a protobuf-era image (-52 and newer) or a pre-0.18 image - aborts with this IOException because the reader has no parsing rules for that layout.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/tools/offlineImageViewer/ImageLoaderCurrent.java:161

      if(v == version) return true;

    return false;
  }

  /* (non-Javadoc)
   * @see ImageLoader#processImage(java.io.DataInputStream, ImageVisitor, boolean)
   */
  @Override
  public void loadImage(DataInputStream in, ImageVisitor v,
      boolean skipBlocks) throws IOException {
    boolean done = false;
    try {
      v.start();
      v.visitEnclosingElement(ImageElement.FS_IMAGE);

      imageVersion = in.readInt();
      if( !canLoadVersion(imageVersion))
        throw new IOException("Cannot process fslayout version " + imageVersion);
      if (NameNodeLayoutVersion.supports(Feature.ADD_LAYOUT_FLAGS, imageVersion)) {
        LayoutFlags.read(in);
      }

      v.visit(ImageElement.IMAGE_VERSION, imageVersion);
      v.visit(ImageElement.NAMESPACE_ID, in.readInt());

      long numInodes = in.readLong();

      v.visit(ImageElement.GENERATION_STAMP, in.readLong());

      if (NameNodeLayoutVersion.supports(Feature.SEQUENTIAL_BLOCK_ID, imageVersion)) {
        v.visit(ImageElement.GENERATION_STAMP_V2, in.readLong());
        v.visit(ImageElement.GENERATION_STAMP_V1_LIMIT, in.readLong());
        v.visit(ImageElement.LAST_ALLOCATED_BLOCK_ID, in.readLong());
      }

      if (NameNodeLayoutVersion.supports(Feature.STORED_TXIDS, imageVersion)) {

View on GitHub (pinned to 2add963021)

Solutions

  1. Use the modern protobuf tool: `hdfs oiv -p XML|Indented|Delimited -i <fsimage> -o <out>`
  2. Run the oiv binary from the same Hadoop release (or newer) as the NameNode that wrote the fsimage
  3. Confirm the image format first (first 4 bytes of the file are the layout version; protobuf images also fail oiv_legacy immediately) and pick the matching tool
  4. Reserve oiv_legacy strictly for genuine Hadoop 0.20/1.x images with layout -16..-51

Example fix

# before
hdfs oiv_legacy -p Indented -i fsimage_0000000000000060000 -o out.txt
# IOException: Cannot process fslayout version -66

# after
hdfs oiv -p Indented -i fsimage_0000000000000060000 -o out.txt
Defensive patterns

Strategy: validation

Validate before calling

// Peek the layout version before handing the file to the legacy loader
try (DataInputStream in = new DataInputStream(
        new BufferedInputStream(new FileInputStream(fsImagePath)))) {
  int layoutVersion = in.readInt(); // first field of an fsimage
  if (layoutVersion > -16 || layoutVersion < -51) {
    throw new IllegalArgumentException(
        "oiv_legacy supports layout -16..-51; this image is " + layoutVersion
        + " - use the protobuf `hdfs oiv` from the matching Hadoop release");
  }
}

Prevention

When it happens

Trigger: `hdfs oiv_legacy -p Indented -i fsimage_XXX -o out` on an fsimage written by a Hadoop 2.x/3.x NameNode (protobuf layout, e.g. -66), by a release newer than the tool, or older than layout -16; also calling ImageLoader.loadImage / ImageLoaderCurrent.loadImage directly on such a file.

Common situations: Mixing Hadoop distro versions (old oiv binary pointed at a new cluster's image); legacy monitoring scripts still invoking oiv_legacy after a cluster upgrade to 2.x+; admins unaware that modern fsimages must go through the protobuf-based `hdfs oiv`.

Related errors


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