IBM Power Systems 775 Manual page 116

/gpfslog/
This entry is an example of a user-defined directory in which we chose to store GPFS
tracing logs. The directory needs to be persistent in the event the node becomes
inoperable and persistent tracing data must be used to debug after the node is returned to
a usable state. GPFS tracing logs become large so they are recommended only for testing
and debugging purposes.
/var/adm/ras/errlog
The errlog is explicitly made persistent. Originally, we made the entire /var/adm/ras
directory persistent, but we found that the console cannot be NFS mounted. You continue
to make /var/adm/ras directory persistent and use swcons after boot to move the conslog
or only statelite mount /var/adm/ras/errlog. (A postscript is required to create the initial
errlog.)
/var/adm/ras/gpfslog/
By default, GPFS logs data from the mmfs log files to /var/log/ras and rotates copies by
appending the date to the files. Therefore, it is impossible to explicitly list these files in the
litefile table. As a result, a logDir attribute is added to GPFS. This entry is used during
configuration to route logs to /var/adm/ras/gpfslog instead of /var/log/adm.
/var/mmfs/
This directory contains the GPFS configuration for each node. After reboot, the node uses
this information to join the GPFS cluster.
/var/spool/cron/
This entry allows for the crontab to be persistent.
If you need to modify the statelite configuration, you do so without updating your image. You
must reset the node configuration file so that after the statelite config is updated, you rerun
mkdsklsnode for AIX and genimage for Linux. You verify the run by reviewing the
/install/nim/shared_root/<image_name>_shared_root/litefile.table file on the service
node.
Any changes must be carefully reviewed and tested before implemented in production
because unexpected circumstances might occur. In one test, the /tmp/serverlog for PSND
logging was added to the statelite configuration and MPI response time was adversely
affected. Therefore, the entry was removed from the statelite configuration. An alternative was
to use the /etc/PNSD configuration file to define a location, such as GPFS.
The following considerations must be reviewed when statelite is used:
Avoid making configuration files statelite. Subsequent code updates might add parameters
that are overwritten by the old configuration file that is mounted over NFS during boot.
In Linux, the kernel must be mounted via statelite. Ensure that when a kernel change is
made, the data on the NFS-mounted statelite directory is removed before boot.
Think about space when directories and files are added to statelite. By default, the data is
stored on the Service Node and has limited disk space. Ensure that the file system that
contains the statelite data has adequate space because all of the nodes are writing to the
file system. Filling up the file system leads to adverse affects when applications are run.
An external NFS server to which extra disk is added is used and defined in the statelite
table instead of in the service node.
An example of a statelite system is shown in Example 2-2 on page 103.
102
IBM Power Systems 775 for AIX and Linux HPC Solution