AIX Version 4.3 Differences Guide

The maximum number of file descriptors per process is defined by the constant
OPEN_MAX. In AIX 4.3.1 it is 32767.
However, this change can create certain compatibility problems with programs
that were compiled with the old OPEN_MAX value of 2000. So there must be a
way to enforce the old OPEN_MAX value for existing programs, yet allow new
programs to exploit the new capability. This has been done with the existing
resource limit functions. There was already a limit for number of available file
descriptors, but it has always been set to RLIM_INFINITY. In AIX 4.3.1, the
setrlimit() and getrlimit() system calls can be used to maintain specific values for
RLIMIT_NOFILE. By default, the soft limit will be the old value of OPEN_MAX,
2000. The default and maximum hard limit will be the new OPEN_MAX value,
32767. With these limits, everything should continue to work as before with no
user intervention. If a user increases the soft limit, then programs written to
exploit the increased table size can be used.
In addition to the system calls for managing limits, the user can change their limit
for number of file descriptors with the ulimit -n command. Because the hard limit
is set to OPEN_MAX, any user can increase the limit, privileged access is not
required.
2.10 Multiple Concurrent JFS Reads (4.3.1)
AIX uses a simple lock type to serialize access to the in-core inode of a file or
directory on a JFS file system. This is to ensure data integrity, particularly on MP
systems, where multiple threads can be accessing an inode simultaneously.
When reading a file, the lock is used to serialize updates to the last access time
stamp in the inode. This lock has been identified as a potential performance
bottleneck in the situation where multiple threads are attempting to read the same
file, particularly when migrating from UP to MP systems.
This type of problem affects customers who use databases on JFS file systems
and do not have a choice because their database application does not support
raw partitions. Examples include Progress, and Universe, to name two. There are
also some large customers who use JFS for their databases. The problem stems
from the length of time the lock is held. A thread would obtain the lock and then
initiate the I/O to read the required data before updating the access time field in
the inode and releasing the lock. During this time, other threads would be blocked
from accessing the file.
To alleviate this problem, AIX 4.3.1 has changed the mechanism for reads from
JFS file systems to minimize the length of time the inode lock is held by a thread.
When only one thread is reading the file, no change has been made. The reading
thread obtains the inode lock and sets a flag in the inode to indicate that a read
operation is in place. When the I/O for the read is complete, the thread updates
the access time field in the inode and releases the lock.
When a thread attempts to get the inode lock and determines that a read is in
progress, instead of blocking on the inode lock, it calls a kernel service to
pre-read the data it requires. Once the pre-read has completed, the thread will
attempt to obtain the inode lock to update the access time field. This solution
reduces the amount of time a thread is required to hold the inode lock when
20 AIX Version 4.3 Differences Guide