I am at a customer site configuring a 4-way, 1GB main memory Dell 6400
system to run Informix 9.2x under RedHat Linux Enterprise Edition 6.2.
The system is running a kernel (2.2.14-6.1.1smp) installed by Dell at the
factory. The system has 36GB of disk (4 9GB spindles) connected to an AMI
PERC2 raid controller on the first of the two available channels on the
card. There is no other disk on this system, although there is CDROM and
4mm DAT tape connected to another SCSI chain (Adaptec, on the mainboard).
The RAID controller presents the disk to the OS as one very large disk.
The RAID controller firmware has been configured to create a RAID-5 volume
from the four disks (no hot spares, four stripes, 64K I/O units).
I modified Dell's partition map to break their sda10 (a 17GB partition
mounted on /usr2) into the smaller partitions spec'ed by the customer.
The partition map is now:
Disk /dev/sda: 255 heads, 63 sectors, 3276 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 5 40131 de Unknown
/dev/sda2 6 528 4200997+ 83 Linux
/dev/sda3 * 529 531 24097+ 83 Linux
/dev/sda4 532 3276 22049212+ 5 Extended
/dev/sda5 532 793 2104483+ 83 Linux
/dev/sda6 794 924 1052226 83 Linux
/dev/sda7 925 990 530113+ 82 Linux swap
/dev/sda8 991 1056 530113+ 83 Linux
/dev/sda9 1057 1089 265041 83 Linux
/dev/sda10 1090 1344 2048256 83 Linux
/dev/sda11 1345 1599 2048256 83 Linux
/dev/sda12 1600 1854 2048256 83 Linux
/dev/sda13 1855 2109 2048256 83 Linux
/dev/sda14 2110 3276 9373896 83 Linux
sda10-sda13 are 2GB partitions intended to be used as raw partitions by
Informix(approximately 2GB, because of cylinder boundary roundoff).
The use of raw partitions for informix data space is a customer
sda1 is Dell's utility partition. Root (/) is sda6, /boot is sda3(below
the 1024 cylinder recommendation). swap is sda7 and is undersized by my
rule of thumb, but is probably adequate.
I created the linkage between the "raw" devices and the block devices
using the "raw" command.
[root@isp5667 informix]# raw -qa
/dev/raw/raw1: bound to major 8, minor 10
/dev/raw/raw2: bound to major 8, minor 11
/dev/raw/raw3: bound to major 8, minor 12
/dev/raw/raw4: bound to major 8, minor 13
[root@isp5667 informix]# ls -l /dev/raw/raw[1-4]
crw-rw---- 1 informix informix 162, 1 Oct 4 1999 /dev/raw/raw1
crw-rw---- 1 informix informix 162, 2 Oct 4 1999 /dev/raw/raw2
crw-rw---- 1 informix informix 162, 3 Oct 4 1999 /dev/raw/raw3
crw-rw---- 1 informix informix 162, 4 Oct 4 1999 /dev/raw/raw4
[root@isp5667 informix]# ls -l /dev/sda1[0-3]
brw-rw---- 1 root disk 8, 10 May 5 1998 /dev/sda10
brw-rw---- 1 root disk 8, 11 May 5 1998 /dev/sda11
brw-rw---- 1 root disk 8, 12 May 5 1998 /dev/sda12
brw-rw---- 1 root disk 8, 13 May 5 1998 /dev/sda13
[root@isp5667 informix]# ls -l /dev/rawctl
crw------- 1 root root 162, 0 Oct 4 1999 /dev/rawctl
I performed the following tests to check that the raw partitions were
dd if=/dev/zero of=/dev/raw/raw3 bs=512 count=10
dd if=/dev/raw/raw3 of=/dev/null bs=512 count=10
Both exited with a return code of 0 (zero).
Hokay. I turned the machine over to the DBA and went off to find
something useful to do. He returned some time later, reporting that
Informix was reporting a system return code 75 when trying to read the
partitions. Here is an Informix log excerpt:
Tue Aug 22 16:34:11 2000
16:34:11 Event alarms enabled. ALARMPROG='/usr/informix/etc/no_log.sh'
16:34:11 Booting Language <c> from module <>
16:34:11 Loading Module <CNULL>
16:34:11 Booting Language <builtin> from module <>
16:34:11 Loading Module <BUILTINNULL>
16:34:16 Informix Dynamic Server 2000 Version 9.21.UC2
Software Serial Number AAC#XXXXXXX
16:34:17 I/O read chunk 1, pagenum 15, pagecnt 1 --> errno = 75
My suspicion was that this was an interaction between the hardware RAID
controller and the raw device driver. I obtained resources to cable the
drives in a JBOD configuration as a way to bypass the RAID controller
using the onboard Adaptec AIX-7xxx controller. The error 75 persisted.
No error message appears in any system logs.
Disabling lfs support caused the errno 75 to go away. See my other report
for details of the kvm problem we then resolved by disabling the bigmem
errno 75 is EOVERFLOW, and it is returned if large files are
opened without the O_LARGEFILE flag.
That goes away without the lfs patch because without lfs the
writes are simply quietly truncated instead of a warning being
I should have mentioned that if you make your partitions any smaller than
2GB, the lfs kernel should work fine.
Update: the errata kernel (2.2.16-4lfs) has this problem as well. Making the
partitions smaller than 2GB did not resolve the issue. Our workaround was to use
the 2.2.16-4 kernel (same kernel without lfs support).
Trimming the cc: list. Is this still an issue with recent errata kernels?
This issue hasn't been commented on for over a year.
I'm not convinced it was ever really an issue. I think it was merely that
Informix wasn't actually using O_LARGEFILE, and the system was working as
designed, and the "workaround" was actually doing the right thing according
to how Informix was coded.