apache/hadoop · error · CorruptMetaHeaderException

The meta file length {metaIn.getLength()} is less than the e

Error message

The meta file length {metaIn.getLength()} is less than the expected length {expectedHeaderSize}

What it means

Every block meta file starts with a fixed-size BlockMetadataHeader (version + checksum-type/chunk info, expectedHeaderSize bytes). If the existing meta file is shorter than that header, it is truncated garbage, so CorruptMetaHeaderException is thrown after a WARN that the meta file is corrupt — the checksum layout cannot even be parsed, let alone verified.

Source

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

            // header and 0 byte in the block data file.
            // Checksum verification is not performed for replicas on transient
            // storage.  The header is important for determining the checksum
            // type later when lazy persistence copies the block to non-transient
            // storage and computes the checksum.
            int expectedHeaderSize = BlockMetadataHeader.getHeaderSize();
            if (!replica.isOnTransientStorage() &&
                metaIn.getLength() >= expectedHeaderSize) {
              checksumIn = new DataInputStream(new BufferedInputStream(
                  metaIn, IO_FILE_BUFFER_SIZE));

              csum = BlockMetadataHeader.readDataChecksum(checksumIn, block);
              keepMetaInOpen = true;
            } else if (!replica.isOnTransientStorage() &&
                metaIn.getLength() < expectedHeaderSize) {
              LOG.warn("The meta file length {} is less than the expected " +
                  "header length {}, indicating the meta file is corrupt",
                  metaIn.getLength(), expectedHeaderSize);
              throw new CorruptMetaHeaderException("The meta file length "+
                  metaIn.getLength()+" is less than the expected length "+
                  expectedHeaderSize);
            }
          } else {
            LOG.warn("Could not find metadata file for " + block);
          }
        } catch (FileNotFoundException e) {
          if ((e.getMessage() != null) && !(e.getMessage()
              .contains("Too many open files"))) {
            datanode.data.invalidateMissingBlock(block.getBlockPoolId(),
                block.getLocalBlock());
          }
          throw e;
        } finally {
          if (!keepMetaInOpen) {
            IOUtils.closeStream(metaIn);
          }
        }

View on GitHub (pinned to 2add963021)

Solutions

  1. Treat the replica as corrupt: remove the truncated blk_*.meta (and its block file) so the datanode reports the replica invalid and the NN re-replicas the block.
  2. Run a filesystem check (xfs/zfs scrub, SMART) on the affected volume — one truncated meta often means a failing disk.
  3. Confirm re-replication completes with 'hdfs fsck <file> -files -blocks -locations'.
  4. Prevent: avoid hand-copies of storage dirs and ensure meta files are included/complete in any DR procedure.
Defensive patterns

Strategy: fallback

Type guard

static boolean isCorruptMetaHeader(IOException e) {
  return e instanceof CorruptMetaHeaderException;
}

Try / catch

try {
  sender = new BlockSender(block, 0, -1, /*verifyChecksum*/true, ...);
} catch (CorruptMetaHeaderException e) {
  markReplicaCorruptAndRequeue(block); // remove replica, NN re-replicates
  sender = buildFromHealthyReplica();
}

Prevention

When it happens

Trigger: metaIn.getLength() < expectedHeaderSize for a non-transient replica: the .meta file was truncated by a crash mid-write, disk corruption, or a partial copy of the storage directory; reading then demands checksum verification.

Common situations: Power loss truncating meta files; bad disk sectors hitting the (small) meta file; operators or backup tools that copied block files incompletely.

Related errors


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