🚨 Linux Error Guide: 'Value too large for defined data type' — Enable Large File Support

Overview

Two closely related errors trip up 32-bit programs running on modern 64-bit systems. Both boil down to a number that no longer fits the integer type a program expected:

Value too large for defined data type
Numerical result out of range

The first is EOVERFLOW (errno 75). The kernel returns it when a value it must hand back, most often a file size, inode number, or offset, does not fit the caller’s declared field width. The second is ERANGE (errno 34), returned by conversion and lookup functions such as strtol, strtod, and getpwnam_r when a result overflows the target type or a supplied buffer is too small.

You are most likely to meet EOVERFLOW when a legacy 32-bit binary calls stat() on a file that has a large inode number or a size above 2 GiB on a 64-bit filesystem such as XFS. This guide separates the two errno values, shows how to prove which syscall failed, and covers the real fixes: rebuilding with Large File Support, moving to a 64-bit build, or using filesystem mount options as a workaround.

Symptoms

• A 32-bit tool prints stat: Value too large for defined data type on a specific file while newer files work fine.
• Backup, archiving, or antivirus software fails only on certain volumes, typically XFS mounted with 64-bit inodes.
• A program parsing numeric input aborts with Numerical result out of range on large numbers.
• perror or a log line reports errno 75 (EOVERFLOW) or errno 34 (ERANGE).
• The failure is deterministic per file: the same file always fails, small files in the same directory succeed.

Common Root Causes

1. 32-bit stat() without Large File Support. The legacy struct stat uses a 32-bit st_ino and a signed 32-bit off_t. If a file’s inode number exceeds 2^32-1, or its size exceeds 2 GiB, the kernel cannot represent the value in the old structure and returns EOVERFLOW. Programs must be compiled to use stat64/struct stat64.
2. 32-bit apps on XFS with 64-bit inodes. XFS allocates inodes across the whole device by default (inode64), so inode numbers routinely exceed the 32-bit range on large filesystems, triggering EOVERFLOW in unmodified 32-bit binaries.
3. Files larger than 2 GiB opened without LFS. A 32-bit off_t cannot address beyond 2 GiB, so open, lseek, or stat on a big file overflows.
4. strtol/strtod overflow (ERANGE). Converting a string whose value exceeds LONG_MAX or DBL_MAX sets errno to ERANGE.
5. Buffer-sizing functions returning ERANGE. getpwnam_r, getgrnam_r, and sysconf-sized calls return ERANGE when the caller’s buffer is too small for the result.

Diagnostic Workflow

First confirm what the binary actually is. A 32-bit ELF is the strongest clue that LFS is the culprit:

file ./app

Trace the failing syscall to see the exact errno and which file it was operating on:

strace -e trace=stat,fstat,lstat,openat,statx ./app

Look for a line ending in = -1 EOVERFLOW (Value too large for defined data type). The path in that syscall is your problem file.

Inspect the file’s inode number and size. A very large inode number confirms the 32-bit overflow theory:

ls -i /path/to/file
stat /path/to/file

Identify the filesystem type and, for XFS, its inode allocation geometry:

findmnt -no FSTYPE,SOURCE,TARGET /path/to/file
df -T /path/to/file
sudo xfs_info /path/to/mountpoint

Check the mount options in effect to see whether inode64 (the modern default) or inode32 is active:

findmnt -no OPTIONS /path/to/mountpoint
mount | grep /path/to/mountpoint

Example Root Cause Analysis

A monitoring agent shipped as a 32-bit binary began failing on a newly provisioned 20 TB XFS data volume, logging Value too large for defined data type for a handful of files. Smaller, older files scanned without issue.

file ./agent reported ELF 32-bit LSB executable, Intel 80386. Running the scan under strace narrowed it down:

strace -e trace=stat,statx ./agent /data/reports/2026-q2.dump

The trace showed stat("/data/reports/2026-q2.dump", 0x...) = -1 EOVERFLOW (Value too large for defined data type). Then ls -i on that file printed an inode number well above 4.29 billion (2^32), while a working neighbor file had a small inode number. xfs_info confirmed the volume and findmnt showed the inode64 mount option in force.

The root cause was unambiguous: the 32-bit agent’s struct stat could not hold the 64-bit inode number that XFS had assigned on this large device. The correct long-term fix was to deploy the vendor’s 64-bit build of the agent. As an immediate, reversible mitigation, the team remounted the volume with inode32, forcing XFS to keep inode numbers within the 32-bit range:

sudo mount -o remount,inode32 /data

New allocations then received low inode numbers, and existing large-inode files were migrated by copying them so XFS reassigned them within range.

Prevention Best Practices

• Compile with Large File Support. For 32-bit builds, define _FILE_OFFSET_BITS=64 (which makes off_t and the stat family 64-bit transparently). The older -D_LARGEFILE_SOURCE and -D_LARGE_FILE_SOURCE macros expose the *64 interfaces where needed.
• Prefer 64-bit builds. On a 64-bit platform, a native 64-bit binary has 64-bit off_t and ino_t by default and never hits this class of overflow.
• Audit legacy binaries early. Run file across shipped binaries so you know which are 32-bit before they meet a large filesystem.
• Know your XFS geometry. Understand that inode64 is the default and is correct for modern software; reach for inode32 only as a compatibility bridge for binaries you cannot rebuild.
• Handle ERANGE in code. After strtol/strtod, always check errno == ERANGE. For getpwnam_r, grow the buffer using sysconf(_SC_GETPW_R_SIZE_MAX) and retry when it returns ERANGE.

Quick Command Reference

# Identify the binary and the failing call
file ./app                                   # 32-bit vs 64-bit ELF
strace -e trace=stat,fstat,lstat,openat,statx ./app

# Inspect the offending file
ls -i /path/to/file                          # inode number
stat /path/to/file                           # size and inode

# Filesystem and mount options
findmnt -no FSTYPE,OPTIONS /path/to/mountpoint
df -T /path/to/file
sudo xfs_info /path/to/mountpoint

# XFS workaround for un-rebuildable 32-bit apps
sudo mount -o remount,inode32 /path/to/mountpoint

# Rebuild with Large File Support (32-bit builds)
cc -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE_SOURCE -o app app.c

Conclusion

Value too large for defined data type (EOVERFLOW) and Numerical result out of range (ERANGE) are the visible symptoms of a number outstripping the type meant to hold it. For file operations the usual villain is a 32-bit program built without Large File Support meeting a large inode number or a file over 2 GiB, especially on XFS with its default inode64 allocation. Prove it with file and strace, confirm with ls -i and xfs_info, and fix it properly by shipping a 64-bit build or recompiling with _FILE_OFFSET_BITS=64. When a rebuild is impossible, an inode32 remount buys you time. For ERANGE, check errno after numeric conversions and resize buffers on demand. Either way, the errno tells you exactly which boundary you crossed.