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 requirement. 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 accessable: 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 feature.
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 issued.
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.