Bug 17123 - Informix/6.2E raw file system usage returns errno75
Summary: Informix/6.2E raw file system usage returns errno75
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 6.2EE
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-08-31 03:17 UTC by Stuart E. Johnson
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2001-11-05 16:35:13 UTC

Attachments (Terms of Use)

Description Stuart E. Johnson 2000-08-31 03:17:45 UTC
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 

Comment 1 Michael K. Johnson 2000-08-31 13:40:07 UTC
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

Comment 2 Michael K. Johnson 2000-08-31 13:55:21 UTC
I should have mentioned that if you make your partitions any smaller than
2GB, the lfs kernel should work fine.

Comment 3 Stuart E. Johnson 2000-09-06 16:39:03 UTC
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).

Comment 4 Matt Domsch 2001-11-05 16:35:08 UTC
Trimming the cc: list.  Is this still an issue with recent errata kernels?  
This issue hasn't been commented on for over a year.

Comment 5 Michael K. Johnson 2001-12-06 17:27:29 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.