From the 7.1.15 readme: Issue 9809 - Problem Description UniData -- UniData maintains a table in shared memory that records information about your system's file systems and the available space in each file system. This table is used to quickly determine if a dynamic file has room to expand in its current directory or if a new part file needs to be created in another file system. The table is loaded when the database starts and is refreshed regularly by the smm daemon.
Prior to this release, the smm daemon created entries in this table
by forking the UNIX 'df' command. As smm relied on the specific
format produced by the standard OS-provided df command, if an
administrator replaced the standard 'df' command with a different
df utility, smm was unable to properly parse the df output and
create proper entries in the shared memory table. This could
result in the inability to create or expand UniData dynamic files.
This table can be viewed with the '$UDTBIN/sms -F' command. Here is
an example of the normal, expected output:
# $UDTBIN/sms -F
File system table size (N_FILESYS):200, Used: 13
Device ID Available Space NFS File System Name
(in 512 Bytes)
1073741827 621296 no /
1073741825 755264 no /stand
1073741833 1209600 no /var
1073741834 1736512 no /usr
1073807361 91514582 no /tshp1123
1073741832 1002224 no /tmp
1073741831 1027440 no /opt
1073741830 1320720 no /home
1073741829 9326052 no /disk2
1073741828 2599142 no /disk1
Starting with this release, smm no longer forks df to create the
entries in this table. Instead, smm reads the platform-appropriate
mount table to create the file system entries in this table. As
smm does not fork a df command, any problem with the output format
of a non-standard df command is avoided.
In order to provide compatibility with prior releases, a new
parameter is created in udtconfig: USE_DF. The default setting
for this parameter is: USE_DF=0. This means 'use the new method of
loading the shared memory table by reading the mount table'. If
an administrator prefers to have smm continue to fork df (as in
prior releases), they can set udtconfig USE_DF=1. UniData daemons
must be stopped and restarted to implement any change to the
USE_DF setting.
NOTE: There have been a number of other problems associated with
smm forking df, including: smm core dumping; defunct df processes
spawned by smm. Most of these problems were triggered by the
behavior of 'df' when nfs-mounted files systems became unavailable
to the system. As smm no longer forks df, these problems should
no longer occur at this release.
ADDITIONAL NOTE: Customers have sometimes experienced a problem
with a udt process hanging during initialization when an nfs
mounted partition was unavailable (network or system down). This
behavior may not be completely resolved by the fix for this issue.
This hang was due to smm not responding to the login request from
the udt process - typically because it was hung itself, waiting for
a df process to complete. Even though we now avoid forking df, smm
still re-calculates the space available in each file system every
60 seconds (by default). smm uses a standard UNIX statfs() system
call to determine the space available on a file system. If smm is
checking an nfs file system that is unavailable, that system call
may still hang. The behavior of this varies by UNIX flavor. If
you mount nfs file systems as a HARD mount, this system call may
hang until that remote system becomes available again. smm will
wait on that system call as well. IBM recommends that you consider
using SOFT nfs mounts. There is typically a configurable number of
retries that will be attempted before the system call returns
with a failure status. This allows smm to continue after a brief
pause, waiting for statfs() to return. Please consult your UNIX
support provider for specific information about NFS SOFT mounts
for your platform.
Wally Terhune
U2 Support Architect
IBM Information Management Software
Tel: (303) 773-7969 T/L 656-7969
Mobile: (303) 807-6222
Email: [email protected]
http://www.ibm.com/software/data/u2/support
From: "Symeon Breen" <[email protected]>
To: <[email protected]>
Date: 05/30/2009 05:34 PM
Subject: [U2] unidata hangs
Sent by: [email protected]
Why why why do all unidata processes hang when a mount point dies – even if
the mountpoint is not being used by any udt process ???
This drives me potty – it has happened again today where a mount for some
data sharing went down because the other machine had a network problem.
This mount was not used by any udt process just used at linux to copy some
files etc. Every udt process, telnet sessions, phantoms, uniobjects
processes then hangs. I have had to unmount the offending mount and stop
and start unidata killing off all sorts of things !
Is there a way to stop this happening ? a different type of mount, a udt
param, a udt upgrade (we are on 7.1)
Cheers
Symeon.
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
