Oninit
Talk to an expert →

Informix Error -69

-69 Disc quota exceeded.

An operating-system error code with the meaning shown was unexpectedly returned to the database server. A disk-quota limit is probably configured in your operating system. Look for other operating-system error messages that might give more information, particularly the disk involved. Contact your system administrator to inquire about more liberal quotas.

Oninit® Troubleshooting Guidance

This is an operating-system error number, not an Informix diagnosis.

The same errno is returned by many different operations, so on its own it says what the operating system refused, not what Informix was trying to do. Informix will usually have reported a more specific error alongside it — in the message log, in the SQL or ISAM error pair, or in the accompanying assert failure — and that error normally defines the real cause far more precisely than the errno does. Find it before diagnosing from this number alone.

This matters less than it used to. Later versions of the engine trap many of these conditions and report them as specific Informix errors naming the operation, the object and the context, so a bare errno in this range is increasingly a sign of an older version, an unusual code path, or a failure early in startup before the better reporting is available. If you are seeing one on a current version, the more specific error is worth looking for even harder.

Important platform note. Error codes in this range represent operating-system errno values whose meanings vary between Unix platforms and versions. Confirm the native errno definition on the server where the Informix error occurred before diagnosing the problem from the number alone.

Determine the Native Error Meaning
Value Symbol
Catalogue text — Disc quota exceeded 69 EDQUOT on BSD
The same condition on Linux 122 EDQUOT — Disk quota exceeded
Errno 69 on Linux 69 ESRMNT — Srmount error, STREAMS-era 
python3 -c 'import os; print(69, os.strerror(69)); print(122, os.strerror(122))'
What EDQUOT Actually Tells You

A write was refused because the owner of the file has reached a quota on that filesystem — not because the filesystem is full.

That distinction produces the signature symptom, and it is what makes this error worth recognising quickly:

df shows plenty of free space and writes fail anyway.

Anyone checking free space first — which is everyone — concludes the storage is fine and looks elsewhere. The filesystem is fine. The allowance for one account on it is not.

The confusable pair:

Error Symbol Linux What is exhausted df shows
-28 ENOSPC 28 The filesystem Full
-69 EDQUOT 122 One account's allowance Space available
Two quotas, and two kinds of limit

Quotas are applied per user and per group, and each has two independent allowances:

  • Block quota — how much space the account may occupy.
  • Inode quota — how many files it may own. A backup scheme creating many small files can exhaust this while using very little space, which produces the same error with an even more confusing df.

Each allowance has a soft and a hard limit:

  • Exceeding the soft limit is permitted for a grace period, after which it behaves like a hard limit.
  • Exceeding the hard limit fails immediately.

The grace period explains the commonest report on this error: "it worked yesterday." Nothing changed except the expiry of a timer that started when the soft limit was first crossed, possibly days earlier.

What This Means in Informix

Quotas apply to whichever account owns the files — the instance owner, which on a non-root installation is neither informix nor root but whichever account ran the installer.

Where it bites, roughly in order of consequence:

  • Logical log backups failing. The most serious. If logical logs cannot be backed up they are not freed, and an instance whose logs fill will stop processing transactions. A quota on the log-backup destination converts a storage-allowance problem into a halted instance.
  • Archives and backups failing mid-write, leaving a partial file that may look complete to a scheduler checking exit status rather than content.
  • Extending a cooked chunk, or adding one, on a filesystem where the owner is over allowance.
  • $INFORMIXDIR/tmp, DUMPDIR and the message log — a message log that cannot be written removes the evidence you would normally use, which is the same trap as -30.
  • External table unloads and staging areas.
  • Temporary space in a DBSPACETEMP directory.

The log-backup case deserves the attention. It is the one where a quota — an administrative setting on a filesystem, often applied estate-wide by someone with no knowledge of the database — can stop a production instance.

Common Causes
  1. A soft limit whose grace period has expired, with nothing else having changed.
  2. A hard block quota reached on a backup or log-backup destination.
  3. An inode quota reached by a scheme creating many small files, while space remains.
  4. A quota applied estate-wide to home directories or shared filesystems, catching the instance owner incidentally.
  5. Backup retention not pruning, so the allowance is consumed gradually until it is not.
  6. A group quota rather than a user quota, which is easy to overlook when checking the owner's allowance alone.
  7. A non-root installation's owner having an ordinary user's quota, where nobody realised a database was running as that account.
Diagnostic Checks

Confirm the symbol, since errno 69 on Linux is ESRMNT:

python3 -c 'import os; print(69, os.strerror(69)); print(122, os.strerror(122))'

Check the quota for the account that owns the files, not for yourself:

quota -u <instance-owner>
quota -v -u <instance-owner>
quota -g <instance-group>

Disk quotas for user ifxprod:
 Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
 /dev/sdb1  20971520 20971520 23068672  none   4127    0       0
                              ^^^^^^^^ hard      ^^^^ soft reached, grace expired

Look at both allowances. The inode columns on the right are where a many-small-files scheme fails while space looks healthy.

Confirm quotas are actually in force on the filesystem:

findmnt -T /path -o TARGET,SOURCE,FSTYPE,OPTIONS
grep -iE 'usrquota|grpquota|prjquota' /proc/mounts
quotaon -p -a
repquota -a 2>/dev/null | head -20

Compare against free space, which is the comparison that identifies this error:

df -h /path
df -i /path
quota -v -u <instance-owner>

Free space in df alongside a quota at its limit is conclusive.

Test as the owning account rather than reasoning about it:

su - <instance-owner> -c 'dd if=/dev/zero of=/path/.qtest bs=1M count=10 2>&1; rm -f /path/.qtest'

Running that test as root proves nothing — root is generally exempt from quotas, which is exactly why a check run by an administrator shows the filesystem working.

Establish the Informix impact, and check the logs first:

onstat -
onstat -l                                   # logical log status — how full
tail -300 "$INFORMIXDIR/tmp/online.log"
tail -100 "$BAR_ACT_LOG" 2>/dev/null

onstat -l is the urgent check where log backups are the thing failing.

Solutions / Resolution
  1. Check the logical logs first. If log backups are what failed, the instance is on a clock — logs that cannot be freed will fill, and a full log stops transaction processing. That is the part to resolve before investigating the quota.
  2. Compare df against quota before anything else. Free space with an exhausted allowance is the signature, and it is what distinguishes this from -28.
  3. Check the quota as the owning account, and do not test as root. Root's exemption makes a broken configuration look healthy.
  4. Look at inodes as well as blocks. A backup scheme creating many small files exhausts the file allowance while using almost no space.
  5. If a grace period expired, that is the change. Nothing else needs to have happened, and the soft limit was probably crossed days before the failure.
  6. Raise the allowance or free space within it — but establish which. Pruning old backups solves it properly; raising the quota postpones it if retention is the real problem.
  7. Question whether the instance owner should have a quota at all. A database account caught by an estate-wide policy for ordinary users is a configuration accident, and exempting it is usually the correct answer rather than raising the number.
  8. Check every filesystem the instance writes to, not just the one that failed. A policy applied broadly will catch the others on their own schedule.
Examples
Free space, and writes failing
$ df -h /backups
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       4.0T  1.2T  2.6T  32% /backups

$ quota -v -u ifxprod
Disk quotas for user ifxprod:
 Filesystem   blocks    quota     limit   grace   files  quota  limit
 /dev/sdb1  20971520 20971520  20971520    none  128441      0      0

Two and a half terabytes free, and the account is exactly at its hard limit of 20 GB. Every check anyone would normally run says the storage is healthy.

The grace period, not a change
$ quota -v -u ifxprod
 Filesystem   blocks    quota     limit   grace   files  quota  limit  grace
 /dev/sdb1  21500000 20971520  23068672  expired   4127      0      0

Over the soft limit, under the hard limit, and the grace period has expired — so writes now fail as though the hard limit had been reached. The soft limit was crossed at some earlier point nobody noticed, and the failure date is the end of the grace period rather than the date anything changed.

That is the whole explanation for "it worked yesterday and nothing was altered", and it is true: nothing was.

Platform Note
Platform This condition Errno 69 there means
Linux errno 122, Disk quota exceeded ESRMNT — STREAMS-era, unrelated
Solaris, AIX, HP-UX confirm on the host confirm on the host
BSD, Darwin errno 69 this condition
Task Linux Solaris AIX
Check a user's quota quota -v -u <user> quota -v <user> quota -v <user>
Report all quotas repquota -a repquota -a repquota -a
Quota state quotaon -p -a quotaon -v quotaon, lsfs -q
Project quotas prjquota mount option ZFS dataset quotas JFS2 filesets

ZFS on Solaris expresses the same constraint as a dataset quota rather than a per-user one, and zfs get quota,used <dataset> is the equivalent check — with the useful difference that it is visible without knowing which account owns the files.

Related Errors / Related Topics
  • -28 — No space left on device. The error this is mistaken for. df distinguishes them instantly, and the two have different owners: the filesystem against one account's allowance.
  • -68 — Too many users, the other quota-related code, which concerns the quota table rather than an allowance within it and is far less likely to be real.
  • -5 — I/O error, for a write that fails because the storage itself is faulty rather than because of a policy.

Where -69 appears, check quota for the instance owner and check the logical logs. The first identifies the error; the second decides how much time you have.