apache/hadoop · error · IOException

Expecting additional output after line: ${line}

Error message

Expecting additional output after line: ${line}

What it means

DF handles device names longer than the df column: when the filesystem token fills the whole first line with no more tokens on it, DF re-reads the NEXT output line to find the numbers. If there is no third line (<output.size() > 2> fails), it throws IOException 'Expecting additional output after line: <line>'. This is the long-device-name wrap case with nothing wrapped underneath.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/DF.java:186

        sb.append(": " + output.get(0));
      }
      throw new IOException(sb.toString());
    }
    
    String line = output.get(1);
    StringTokenizer tokens =
      new StringTokenizer(line, " \t\n\r\f%");
    
    try {
      this.filesystem = tokens.nextToken();
    } catch (NoSuchElementException e) {
      throw new IOException("Unexpected empty line");
    }
    if (!tokens.hasMoreTokens()) {            // for long filesystem name
      if (output.size() > 2) {
        line = output.get(2);
      } else {
        throw new IOException("Expecting additional output after line: "
            + line);
      }
      tokens = new StringTokenizer(line, " \t\n\r\f%");
    }

    try {
      Long.parseLong(tokens.nextToken()); // capacity
      Long.parseLong(tokens.nextToken()); // used
      Long.parseLong(tokens.nextToken()); // available
      Integer.parseInt(tokens.nextToken()); // pct used
      this.mount = tokens.nextToken();
    } catch (NoSuchElementException e) {
      throw new IOException("Could not parse line: " + line);
    } catch (NumberFormatException e) {
      throw new IOException("Could not parse line: " + line);
    }
  }

View on GitHub (pinned to 2add963021)

Solutions

1. Check the actual output shape: df -k <datadir> | cat -A - if the device wraps onto its own line but numbers are missing, that mount cannot be parsed by this DF version.
2. Point data directories at a mount with a short device name (label/mount via fstab with a stable short path) or use a bind-mount alias.
3. Upgrade Hadoop - DF parsing of wrapped/long device names has been improved in later releases.
4. As a workaround for pure capacity checks, substitute a different mechanism (java.io.File.getUsableSpace) in your own tooling instead of DF.

Example fix

# before
# /dev/mapper/a-very-long-volume-group-name--that-wraps appears alone on its df line
# DF.parseOutput(): IOException: Expecting additional output after line: ...

# after: expose the volume under a short, stable bind mount and use it for data dirs
sudo mkdir -p /grid1
sudo mount --bind /dev/mapper/a-very-long-volume-group-name--that-wraps /grid1
# dfs.datanode.data.dir=/grid1/dn  ->  df -k /grid1/dn parses cleanly

// pre-check: the numeric row must contain >= 5 tokens
// run 'df -k <dir>' yourself; if the device token occupies a whole line with no
// following numeric line, that volume cannot be used with DF-based accounting

try {
  df.getMount();
} catch (IOException e) { // 'Expecting additional output after line:'
  // repoint data dirs at a short-named bind mount or different volume
}

When it happens

Trigger: Running DF against a volume whose df output wraps: very long NFS export names, LVM/device-mapper paths (/dev/mapper/very-long-vg-name-lv), or bind mounts pushing the device token alone onto line 1, while the numeric fields did not follow on a subsequent line.

Common situations: DataNode/NodeManager volumes on long-named LVM or NFS mounts; cloud images with verbose device-mapper names; older Hadoop versions whose DF parser is stricter about the wrap.

Related errors

• Unexpected empty line
• Could not parse line: ${line}
• Fewer lines of output than expected
• value cannot be blank
• ${value} is not in expected format.Expected format is <numbe

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