Michael D. Hensley wrote:
> I seem to recall that on MPE/iX 5.0, there was a problem/feature with
> file allocation on LDEV 1.  As I remember it, if you had more than
> one disc in MPEXL_SYSTEM_VOLUME_SET, MPE would try very, very hard
> not to build new files on LDEV 1.  I also seem to remember that a
> patch was made to fix this.

If there is more than one disc in <long-name> then MPE will not allocate
more than 50% aggregate (perm+trans) of the drive capacity unless there
is *no* suitable space on any other member volume.  You cannot "force"
things either using volutil's allocation percentages, since you cannot
configure anything less than 100% (perm+trans), e.g., you can't set
limits of 80% perm/10% trans, it must be 80/20.  This can of course lead
to serious fragmentation as the drives get full.

The more serious problem was with posix fork().  To perform a fork(),
the parent's data space is "cloned" by a special VSM internal routine.
This routine requires a contiguous extent of transient space on the same
ldev as the parent.  If there isn't adequate contiguous space, rather
than looking elsewhere, it initially aborted the parent; there was
"patch" which changes this to a EAGAIN error from fork() [resource busy,
try again].  But to my knowledge, neither the ldev 1 "conservative
allocation feature" nor the VSM cloning routine has been touched through
5.5 powerpatch 1.  The freeware httpd server is highly prone to the
fork() problem.  The OpenMarket server only at startup and certain cgi
constructs.  I suspect the new "telnet/ix server" aka inetd also may be
prone to fork() problems.  If so, perhaps more users will be reporting
these problems and hopefully escalating a more suitable repair (like
setting the "conservative allocation" percentage, allowing <100%
perm+trans allocations in volutil, and fixing the VSM cloning
procedure).

Jeff Kell <[log in to unmask]>