Informix Error -27

Operating-System Meaning

errno 27 is EFBIG — File too large. A write was refused because it would take the file past a maximum size.

The official text's advice to check what "too large" means in context is fair, because two unrelated ceilings produce this error and they need different remedies:

	Process limit	Filesystem limit
What it is	RLIMIT_FSIZE — a per-process cap on file size	The largest file the filesystem can represent
Set by	ulimit -f, limits.conf, systemd LimitFSIZE	The filesystem type and its format options
Applies to	Files written by that process only	Everything on that filesystem
Fix	Raise the limit, restart the process	Move the data, or use a different filesystem
Gives warning?	No — abrupt at the boundary	No

Both are abrupt. A write succeeds at the boundary and fails at the next byte, so the failure arrives mid-operation rather than at the start — which is why it usually surfaces in a backup or an unload that has been running for some time.

Distinguish it from -28 immediately. ENOSPC means the filesystem has no room left; EFBIG means there is plenty of room and this file may not get any bigger. df looks healthy on a -27 and that is not reassuring — it is the expected result.

What This Means in Informix

Backup and unload output

The most common context. Output that grows without a defined bound:

• ontape writing to disk, where the archive is a single file
• onbar and storage-manager staging files
• Logical log backups accumulated into one file
• dbexport and UNLOAD output from a large table
• External table writes
• online.log, where a long-running instance with verbose logging eventually gets there

Cooked chunks

A cooked chunk is a file and is subject to both ceilings. A chunk cannot be created or extended beyond what the filesystem allows, and the engine's own chunk size limits apply on top of that. Where a chunk will not grow and the filesystem has space, both this error and the engine's own limits are worth checking.

The legacy 2 GB barrier

Worth knowing because Informix estates are old enough to meet it. A 32-bit process built without large file support cannot handle files beyond 2 GB, regardless of what the filesystem allows. In practice this appears as:

• Legacy ESQL/C or 4GL clients writing unload files
• Old custom utilities in the estate that were never rebuilt
• An NFS mount where the server side imposes the limit
• Archived data written by tooling from that era

The signature is a file that stops at almost exactly 2,147,483,647 bytes. Where the engine handles large files correctly and a client does not, the client is the thing to rebuild.

Common Causes

1. RLIMIT_FSIZE set for the installation owner, often inherited from a template or a hardening baseline.
2. A systemd unit with LimitFSIZE, overriding limits.conf as it does for the other limits in this range.
3. The filesystem's maximum file size reached — more likely on older filesystem types or unusual formats.
4. A 32-bit client without large file support hitting 2 GB.
5. An NFS server imposing a limit the client does not.
6. Backup output growing without bound, where no splitting is configured.

Diagnostic Checks

Read the running process's actual limit, in bytes, rather than the shell's:

cat /proc/$(pgrep -o oninit)/limits | grep -i 'file size'
#  Max file size    unlimited   unlimited   bytes

cat /proc/<pid>/limits | grep -i 'file size'

The shell's view is not the process's, and ulimit -f reports blocks whose size depends on the shell — /proc/<pid>/limits is in bytes and unambiguous:

ulimit -f ; ulimit -Hf         # blocks — verify the unit before trusting it
grep -rn fsize /etc/security/limits.conf /etc/security/limits.d/ 2>/dev/null
systemctl show <informix-unit> -p LimitFSIZE

Check the file against both ceilings:

ls -l  /path/to/file
stat -c '%s  %n' /path/to/file
df -T  /path/to/file           # filesystem type matters for the maximum
findmnt -T /path/to/file -o TARGET,SOURCE,FSTYPE,OPTIONS

Rule out -28 explicitly, since the two are easily conflated:

df -h  /path/to/file
df -i  /path/to/file

Ample free space alongside a failed write is the confirmation that this is a size ceiling rather than exhaustion.

Test the filesystem's limit directly rather than reasoning from its type — this creates a sparse file and costs almost nothing:

truncate -s 5T /path/to/fs/.bigtest 2>&1 && ls -l /path/to/fs/.bigtest
rm -f /path/to/fs/.bigtest

A failure here is a filesystem limit; success means the ceiling is elsewhere.

For the 2 GB case, check the writer rather than the filesystem:

file /path/to/client_binary          # 32-bit or 64-bit
ls -l /path/to/output                # stopped near 2147483647?
getconf LFS_CFLAGS                   # large-file support flags for rebuilding

For NFS, check what the server permits:

findmnt -T /path/to/file -o SOURCE,FSTYPE,OPTIONS
mount | grep nfs
# and test on the server itself, where the real limit lives

Solutions / Resolution

1. Establish which ceiling you hit — process or filesystem. /proc/<pid>/limits against df -T answers it, and the remedies share nothing.
2. If it is RLIMIT_FSIZE, raise or remove it, in every place that applies:

   # /etc/security/limits.d/informix.conf
   ifxprod  soft  fsize  unlimited
   ifxprod  hard  fsize  unlimited
   

   # systemd unit, if the instance starts that way
   [Service]
   LimitFSIZE=infinity
   

   The process must be restarted to pick it up — as on -24, a running process keeps the limits it started with. prlimit --pid <pid> --fsize=unlimited is the equivalent stopgap.
3. If it is the filesystem, move the output somewhere with a higher ceiling, or split it. For backups, splitting is usually the better answer regardless: a single enormous archive file is awkward to move, verify and restore from.
4. Configure the backup to split rather than raising limits until one file fits. Check what your version supports for multiple output files or a size-per-file setting.
5. Rebuild 32-bit clients with large file support, or move the work to a 64-bit build. No server-side or filesystem change raises a client's own 2 GB ceiling.
6. For NFS, check the server. A client-side limit change achieves nothing if the export enforces the smaller one.
7. Rotate online.log if that is what reached the ceiling, rather than raising limits around it.

Examples

A process limit nobody set deliberately

$ df -h /informix/backups
Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/vg-backups    4.0T  1.1T  2.9T  28% /informix/backups

$ ls -l /informix/backups/archive_L0
-rw-rw---- 1 ifxprod ifxprod 2147483648 Sep  9 03:41 archive_L0

$ cat /proc/$(pgrep -o ontape)/limits | grep -i 'file size'
Max file size             2147483648           unlimited            bytes

2.9 TB free and the archive stopped dead at exactly 2 GB. The soft limit was 2 GB — almost always inherited from a template or baseline rather than chosen. The hard limit is unlimited, so raising the soft limit needs no privilege, but the process must restart to see it.

The filesystem, not the process

$ cat /proc/$(pgrep -o oninit)/limits | grep -i 'file size'
Max file size             unlimited            unlimited            bytes

$ df -T /informix/chunks
Filesystem     Type  1K-blocks      Used Available Use% Mounted on
/dev/sdb1      ext3  8589934592 412342144 8177592448   5% /informix/chunks

$ truncate -s 5T /informix/chunks/.bigtest
truncate: failed to truncate '/informix/chunks/.bigtest': File too large

No process limit at all. ext3 caps individual files well below what the volume can hold, so a chunk cannot grow past it however much space df reports. The remedy is the filesystem, not Informix.

A legacy client at 2 GB

$ ls -l /informix/unload/sales_history.unl
-rw-rw---- 1 ifxprod ifxprod 2147483647 Sep  9 11:22 sales_history.unl

$ file /informix/bin/legacy_unload
/informix/bin/legacy_unload: ELF 32-bit LSB executable, Intel 80386

$ cat /proc/$(pgrep -o oninit)/limits | grep -i 'file size'
Max file size             unlimited            unlimited            bytes

The engine has no limit and the filesystem is modern. A 32-bit client built without large file support cannot address beyond 2 GB, and stopped one byte short of the signed 32-bit maximum. Rebuilding it is the only fix.

Platform Note

errno 27 is EFBIG on Linux, AIX, Solaris, HP-UX and the BSD-derived systems — stable, so the number is reliable.

Filesystem maxima vary enormously and are the part worth checking rather than assuming:

Task	Linux	Solaris	AIX
Process limit	/proc/<pid>/limits, prlimit	plimit <pid>	/etc/security/limits
Configured limit	limits.conf, systemd LimitFSIZE	process.max-file-size	fsize in /etc/security/limits
Filesystem type	df -T, findmnt	df -n, fstyp	lsfs -v
Test the maximum	truncate -s	mkfile, truncate	truncate

AIX deserves particular attention: the fsize value in /etc/security/limits has historically defaulted to a finite number of blocks rather than unlimited, so the per-process ceiling is more likely to be the cause there than on Linux. Check it before the filesystem.

On Solaris, the project framework governs process.max-file-size, and a process in an unexpected project may carry a limit nobody intended.

Related Errors / Related Topics

• -28 — No space left on device. The error this is most often confused with, and the distinction is sharp: -28 means the filesystem is full, -27 means it has room and this file may not use it. df is healthy on a -27.
• -24 — Too many open files. Shares the pattern that the running process's limits are what matter and ulimit in a shell does not show them.
• -22 — Invalid argument, worth ruling out where a write fails at an unusual offset.
• -5 — I/O error, where the size is not the constraint and the device is failing.

Where -27 stops a backup, the finding is usually that the output has no defined bound. Splitting it and setting a retention policy addresses this error, -28, and the directory-size problem behind -7 at the same time.