Informix Error -15

Operating-System Meaning

errno 15 is ENOTBLK — Block device required. An operation that can only be performed on a block device was given something else: a character device, a regular file, or a directory.

Two things before going further.

It is rare. On modern systems very few operations demand a block device, and mount() is essentially the only one encountered routinely. If you are seeing -15, the failing operation is unusual and the path involved is almost certainly not what the configuration intended.

The official text is more helpful than most in this range. It points directly at "an incorrect address in the chunk-device or tape-device parameters", and that is the right instinct: this error is a configuration problem, and specifically one about what kind of object a path refers to.

Unix has three relevant kinds of object, distinguished by the first character of ls -l output:

ls -l	Kind	Notes
b	Block device	Buffered by the kernel, addressed in blocks
c	Character device	Unbuffered "raw" access
-	Regular file	A cooked file on a filesystem
d	Directory	—

A path that looks right can be entirely the wrong kind of thing, and nothing but an explicit check will reveal it.

What This Means in Informix

The useful content here is not the errno — it is the character-versus-block question for chunk devices, which differs by platform and is a genuine migration trap.

Historically, Informix on Unix used raw (character) devices for chunks, bypassing the filesystem buffer cache so the engine could manage its own I/O. Each platform names the two forms differently, and they are different device nodes for the same storage:

Platform	Character / raw	Block	What Informix chunks normally use
AIX	/dev/rlvname	/dev/lvname	The raw form (r prefix)
Solaris	/dev/rdsk/…	/dev/dsk/…	The raw form (rdsk)
HP-UX	/dev/rdsk/…	/dev/dsk/…	The raw form (rdsk)
Linux	/dev/raw/rawN via raw(8) — deprecated, availability varies	/dev/sdX, /dev/mapper/…	Usually block devices or cooked files with direct I/O

Linux is the exception, and this is where configurations go wrong. The raw(8) binding interface does still exist — it has been marked deprecated for many years and repeatedly slated for removal without that actually happening — but whether it is present depends on the kernel configuration and the distribution, and it should not be assumed. Modern practice on Linux is block devices or cooked files, with direct I/O providing the unbuffered behaviour that a raw node used to.

So the trap is not that raw devices are impossible on Linux; it is that an AIX or Solaris path such as /dev/rlv_data or /dev/rdsk/… has no Linux equivalent by name. Nothing about the naming convention travels. Equally, a Linux configuration naming a block device may be pointing at the wrong node on AIX or Solaris, where the raw form is a separate device entirely.

Check what exists on the host in front of you rather than assuming either way, and check your version's documentation for what it actually expects.

Other contexts for -15:

• Tape device parameters — TAPEDEV, LTAPEDEV, or the equivalent in a backup script, naming the wrong node
• A backup or staging target given a directory where a device was expected, or the reverse
• A mount operation in a wrapper script, given a path that is not a block device
• A chunk path pointing at a regular file where the configuration expected a device, often after a restore recreated a placeholder

Common Causes

1. A chunk or tape path naming the wrong kind of node — character where block is wanted, or the reverse.
2. A configuration carried between platforms whose device-naming convention differs.
3. A path pointing at a regular file or directory rather than a device at all.
4. An AIX or Solaris r-prefixed path used on Linux, where that naming convention has no equivalent.
5. A mount in a wrapper script given a non-block device.
6. A symlink resolving to something other than what was intended.

Diagnostic Checks

Check what the path actually is. This is the whole diagnosis in most cases:

ls -l /path/to/device
stat -c '%F  %n' /path/to/device
file /path/to/device
readlink -f /path/to/device        # resolve symlinks first

brw-rw---- 1 ifxprod ifxprod 8, 49 …   -> block device
crw-rw---- 1 ifxprod ifxprod 8, 49 …   -> character device
-rw-rw---- 1 ifxprod ifxprod   ...     -> regular file
drwxr-x--- 2 ifxprod ifxprod   ...     -> directory

Check every chunk path at once, and print what each one is:

onstat -d | awk '/^[0-9]/ {print $NF}' | while read -r p; do
    r=$(readlink -f "$p" 2>/dev/null || echo "$p")
    printf '%-45s %s\n' "$p" "$(stat -c '%F' "$r" 2>/dev/null || echo MISSING)"
done

A mixture of kinds across chunks in the same instance should be checked even where nothing is currently failing.

Check the tape device parameters against reality:

grep -nE 'TAPEDEV|LTAPEDEV|TAPEBLK|LTAPEBLK' "$INFORMIXDIR/etc/$ONCONFIG"
ls -l "$(grep '^TAPEDEV'  "$INFORMIXDIR/etc/$ONCONFIG" | awk '{print $2}')"
ls -l "$(grep '^LTAPEDEV' "$INFORMIXDIR/etc/$ONCONFIG" | awk '{print $2}')"

If a mount is involved:

findmnt /path/to/mountpoint
mount | grep /path/to/mountpoint
lsblk -o NAME,MAJ:MIN,TYPE,MOUNTPOINT

On Linux, establish whether the raw interface is present on this host rather than assuming — it varies by distribution and kernel configuration:

ls -l /dev/raw/ 2>&1
which raw 2>&1              # raw(8), from util-linux
raw -qa 2>/dev/null         # existing bindings, if any
grep -i raw /proc/devices

Note that even where it is available, an AIX or Solaris path name will not resolve — the convention is what does not port, not the capability.

For the platforms that do distinguish, check both nodes exist and which is configured:

# AIX
lsvg -l <vg>            # logical volumes
ls -l /dev/lv_data /dev/rlv_data

# Solaris
ls -l /dev/dsk/c0t0d0s1 /dev/rdsk/c0t0d0s1

Solutions / Resolution

1. Identify what the path is with stat or ls -l before changing anything. The first character of the mode string answers the question.
2. Correct the configuration to name the right node for this platform — not the one that worked on the previous platform. Resolve symlinks when checking, since the link and its target can be different kinds.
3. On Linux, do not carry the raw path across — and prefer not to rely on raw(8) for new work. An AIX or Solaris raw path has no Linux equivalent by name and must be rewritten. The raw binding interface may still be present on the host, but it has been deprecated for many years and is a poor foundation for a new configuration; block devices or cooked files with direct I/O are the durable choice.
4. On AIX, Solaris and HP-UX, use the raw node for chunks unless your version's documentation says otherwise — the r-prefixed path, which is a different node from the block one for the same storage.
5. Do not create a file to satisfy the path. Putting a regular file where a device was expected will appear to work and will not behave as the configuration assumes.
6. Check the tape parameters separately from the chunk paths; they fail independently and the official text names both for good reason.
7. Re-verify after any storage or platform change, including a restore, since a rebuild can recreate a path as the wrong kind of object.

Examples

A configuration carried from AIX to Linux

$ grep -n datadbs "$INFORMIXDIR/etc/$ONCONFIG"
# chunk path /dev/rlv_datadbs01

$ ls -l /dev/rlv_datadbs01
ls: cannot access '/dev/rlv_datadbs01': No such file or directory

$ lsblk -o NAME,SIZE,TYPE | head -4
NAME         SIZE TYPE
sda          500G disk
sdb            2T disk

An AIX raw logical volume path on a Linux host. The storage is present under entirely different names; the r-prefixed convention simply does not exist here. The chunk must be redefined against a block device or a cooked file — and every other chunk carried across in the same migration needs checking, not just the one that failed.

Whether raw(8) happens to be available on the host is beside the point: it would not make /dev/rlv_datadbs01 resolve, and binding a raw node to reproduce an AIX layout would be building on a long-deprecated interface for no benefit.

The path is a regular file, not a device

$ ls -l /informix/chunks/datadbs2
-rw-rw---- 1 ifxprod ifxprod 0 Sep  9 11:02 /informix/chunks/datadbs2

Zero bytes, regular file. A restore or a rebuild script recreated the path as an empty file where a device node was expected. Nothing here will work as configured, and the fact that the path resolves makes it look healthier than it is.

Block where raw was intended, on Solaris

$ grep -n rootdbs "$INFORMIXDIR/etc/$ONCONFIG"
# chunk path /dev/dsk/c1t2d0s3

$ ls -l /dev/dsk/c1t2d0s3 /dev/rdsk/c1t2d0s3
brw-r-----   1 ifxprod ifxprod  32, 27 … /dev/dsk/c1t2d0s3
crw-r-----   1 ifxprod ifxprod  32, 27 … /dev/rdsk/c1t2d0s3

Both nodes exist for the same slice — same major and minor numbers, different access semantics. The configuration names the block form where the raw form was intended.

Platform Note

errno 15 is ENOTBLK on Linux, AIX, Solaris, HP-UX and the BSD-derived systems, so the number is stable — but this is a case where the number is much less useful than the platform context.

The substantive difference is the one described above. On AIX, Solaris and HP-UX the character/block distinction is a live part of how storage is addressed, with two separate nodes per device. On Linux it is largely historical: the raw(8) interface persists but has been deprecated for many years, its availability varies, and direct I/O on a block device is what is normally used instead. Any runbook, onconfig or provisioning script that encodes device paths is platform-specific for this reason, and is one of the first things to review during a migration.

Where a page or a colleague tells you Informix "requires raw devices", treat that as true of the traditional Unix platforms and not of Linux, and check the documentation for the version and platform in front of you before rebuilding anything.

Related Errors / Related Topics

• -6 — No such device or address. The device node exists but nothing is behind it. Together with -15 these cover the two ways a device path can be wrong without being missing.
• -2 — No such file or directory. The path does not resolve at all.
• -13 — Permission denied on a node that is present and of the right kind.
• -5 — I/O error, where the node is correct and the device is failing.

A -15 during a migration is rarely isolated. Device naming is the part of a configuration least likely to survive a platform change, so check every chunk and tape path in the instance rather than only the one that reported the error.