Memory Segmentation

  • 2908018
  • 23-May-1996
  • 09-Jan-1998
  • 6

Archived Content: This information is no longer maintained and is provided 'as is' for your convenience.

Issue

Introduction

    In the following text the term "Segmentation" will be used frequently.
Therefore, to avoid confusion, a distinction should be made between Segmentation
and another common term, Fragmentation.

    Segmentation is defined as an initialization condition where NetWare
memory is presented in two or more non-contiguous blocks immediately after
server.exe is initialized and all physical memory is registered with NetWare.
These blocks of non-contiguous memory are normally very large, i.e. 16 MB or larger. Segmentation will impact operations like mounting volumes and creating files
and directories. It will not likely have an affect on other processes which use
server memory.

    Fragmentation is a condition where available memory may be broken
into many non-contiguous pieces through the allocation and de-allocation of
memory for NLMs or other NetWare processes. These pieces of available memory
are typically very small, i.e. 4 KB to 64 KB. Fragmentation will often be the result
of many processes using memory over an extended period of time. Fragmentation,
in its most severe forms, will impact all processes which cause memory allocations
to occur.

Memory Allocation Rules for Volume Mounts
    
    At the time a volume mounts, memory tables are created, copied or
built, from structures on the hard disk. If multiple blocks or segments of memory
exist at the time the first volume mounts, then the OS will choose a block in
which it will create the tables. Once the block is chosen, all subsequent tables
from volume mounts will be built in that block. If other blocks or segments exist,
they will not be used for the first or any subsequent volume tables.

    Two key elements in terms of the amount of memory required to mount
a volume are: 1) the File Allocation Table (FAT) and 2) the Directory Hash Table (DHT).
The FAT in memory is just an image of the FAT on the disk. The DHT is derived from the Directory Entry Table (DET) on the disk. It is a hash table, which is simply a table
of pointers to where the directory entry for any given file or directory exists on the
disk. The size of the DHT is directly related to the number of files and directory
entries in the volume's DET.

    Memory for the FAT and DHT is allocated starting at the bottom of a block,
working upward. These allocations must always find contiguous memory, otherwise
the volume in question will not mount.

    As an example, suppose that the volume SYS: is mounting. The FAT has
been copied into memory using up 4M (400000h) bytes from 42A000h to 82A000h.
Suppose further that the SYS: volume has 100,000 files and directories. After the
FAT is loaded into memory, the OS will allocate blocks starting at 82A000h so that
the DHT can be built. Each file and directory will require about 10 bytes for the
hash entry. Therefore, the DHT will require about 10 bytes times 100,000
files/directories or 1,000,000 (F4240h) bytes. Adding the end location of the
FAT (82A000h) to the DHT size (F4240h) yields 91E240h. Finally, suppose
that the OS has allocated a block of memory at address 900000h, just below
91E240h. As the OS allocates memory for the DHT it will not be able to allocate
a block of memory at 900000h and the volume will fail to mount. Even if there
should be an abundance of free memory above the block at 900000h, it cannot
be used for the SYS:'s DHT or any other FATs because it is not contiguous with
the memory currently allocated for FATs and DHTs.

Memory Allocation Rules for NetWare Processes and NLMs
    
    NetWare's memory allocator, used by NLMs and other OS processes,
allocates memory starting at the top of a block, working downward. One
exception to this rule would be the pool of buffers below the 16 MB mark.
That pool is reserved by the set parameter:
set reserved buffers below 16 meg = <number of 4KB buffers>.
Any access to that pool requires the use of a special allocation call,
AllocBuffersBelow16Meg. That pool will always be somewhere below 16 MB.

OS Decisions about Blocks for Mounting Volumes
    
    Given the choice of multiple blocks or segments at the time volumes mount,
NetWare 3.x and NetWare 4.x will respond differently. NetWare 3.x (3.11 or 3.12) will
choose the larger block if given a choice between two blocks.
    
    NetWare 4.x (4.01, 4.02 and 4.10) will always pick the block below 16 MB to
mount volumes. This choice is particularly problematic in the cases where a file server
cannot successfully register memory using the EISA registration method.

Cache Control Structures Cause Segmented Memory
    
    Cache Control Structures are relatively small blocks of memory
allocated for the purpose of managing bigger blocks of memory. If hardware
requires the use of the register memory command or if the SET auto register
memory above 16 megabytes = OFF, then
memory will be segmented. That is, two blocks of memory will be separated
by a cache control structure. Here is why: as the first 16 MB of RAM is registered
with NetWare a cache control structure is allocated at the top of the 16 MB block.
Later, when the manual
register memory command is used to register the remaining memory, another
block of memory will be added. However, the cache control structure will
separate the memory into two blocks or segments, the first 16 MB and memory
above 16 MB, hence the term segmentation.

    NetWare 3.x customers who must manually register memory above 16 MB
will be affected by the problem. However, they may add more RAM and delay
mounting volumes until all memory is registered. By so doing, they will force
volume tables to mount in the larger of the two blocks. Therefore, adding more
memory to the system will always result in a larger block for volumes.

    Unlike 3.x customers, NetWare 4.x (4.01, 4.02 and 4.10) customers
who must manually register have a serious problem because volumes will mount
in the first 16 MB block even if a larger block is available above 16 MB. In this
case, adding more RAM to the system will not result in a larger block for mounting
volumes.

    Special cases include some seen on Compaq EISA machines where the
 NetWare 3.x and 4.01 EISA registration or auto-registration code presented multiple
blocks of memory with cache control structures separating them. These cases were
typically experienced by customers with more than 80 MB of RAM. NetWare code
put the first 16 MB of RAM together with the next 64 MB as a single block and
then created a cache control structure at the top. Additional RAM was then added
in 128 MB segments with cache control structures for each segment, until all of
the physical RAM was registered. By this method, however, a server with 500 MB
of RAM would be presented with five segments, 80, 128, 128, 128 and roughly 30
MB. The 3.x solution for this type of segmentation was to manually register memory.
The solution for 4.01 was the memfrgfx.nlm patch. This fix was rolled into 4.02 and
4.10 NetWare.

Reserved Buffers Below 16 Megabytes May Cause Segmentation

    In NetWare 3.11, 3.12 and 4.01, the Reserve Buffers Below 16 Meg could
cause memory to be segmented. During NetWare's initialization phase, the reserved
buffer pool is allocated somewhere in the first 16 MB of memory. If enough memory
is available below the address where server.exe loads, the buffers will be placed there.
If not, the buffers are allocated at the top of the 16 MB block of memory. In this
configuration, like the case of the cache control structure, memory becomes segmented.
Unless something is done to force a change, volumes will mount in the first 16 MB and
will be trapped by the reserved buffer pool. Reducing the number of reserved buffers
below 16 MB would permit them to be allocated below server.exe, however, most
customers who experience this condition need the large reserved buffer pool for
aspi drivers or other 16-bit drivers. Customers with less than 32 MB total RAM
may have to increase to 32 MB or more and apply the following treatment.

    The solution for NetWare 3.x customers, who have 32 MB of RAM or more,
is to delay the volume mount and register memory manually. This causes volumes to
mount in the block above 16 MB. If more memory is required for volume mounts,
adding more RAM to the server will always result in a bigger segment.

    The memfrgfx.nlm patch fixed the problem in NetWare 4.01 and was
rolled into NetWare 4.02 and 4.10. This fix forced the reserved buffers to always
be allocated below the server.exe code.

LOADER.EXE in release patch kits for NW410 for Newer Systems

    Newer systems which have BIOSes that support the INT15 sub-function
E8 call will permit NetWare 4.10 to create a single block of contiguous memory at
the time memory is registered in the initialization stage. This requires the loader
patch and precludes the need for manual registration of memory. The patch may be obtained
from the latest NW Server patch kits. NetWare 4.11 or intraNetWare 4.11 will already have this
BIOS support and will not require patches.

Symptoms of Memory Segmentation

    Symptoms of memory segmentation will generally be seen at the time
volumes are mounting or when files or directories are being created. The following
conditions and messages are typical.
    
    1) A volume fails to mount with "cache memory allocator out of available
memory" error message at the server console.

    2) A client cannot create a file or directory and an error
"Error expanding <volume name/directory name> because directory size limit was reached"
will appear at the server console and possibly at the client. Additionally, repeated
attempts by the client to copy or ncopy files to the server result in the error
"Not enough Memory" at the workstation.

See also: KB 1003164.

Feedback service temporarily unavailable. For content questions or problems, please contact Support.