* Novell publishes rational view of the NetWare 6.5 memory fragmentation problem
If the right hand doesn’t know what the left hand is doing, bad things can happen. This appears to be the root of the NetWare 6.5 memory fragmentation problem that we’ve been looking at over the past couple of weeks. The bad news is that Novell Technical Information Document # 10091980 has been modified and revised once again (see link below). The good news is that it actually makes sense now.
You’ll remember I hope, that the original version of the TID pointed to the archive module TSAFS.NLM as the culprit in the NetWare 6.5 memory fragmentation issue. A revised version published earlier this month absolved TSAFS of blame and placed it squarely on the operating system (with a few snide remarks about the directory service, DS.NLM). Now a later version of the TID, published just last week, takes a rational, reasoned view of the problem, admits past errors and lays out a short and straightforward method of resolving the issue.
The blame now is placed squarely on the architecture of the Intel CPU design. NetWare, as a 32-bit operating system, can theoretically address 64G bytes of RAM. But the Intel architecture limits any operating system to a 4G-byte area for mapping Logical Memory. RAM beyond this 4G-byte must be mapped in and out via a paging system. It’s analogous to the architecture of the 80286, which drove us all crazy with “extended” and “expanded” memory 15 years ago. You’d think Intel would have learned.
Actually, Intel has used this same, or related, architecture for every CPU it has developed and released for general-purpose PC use. See https://www.dewassoc.com/support/msdos/msdos_memory.htm for more than you’ll want to know about expanded and extended RAM and the Lotus-Intel-Microsoft Expanded-Memory-Standard.
But I digress. The new version of TID # 10091980 lays out four easy steps to overcome the great majority of memory fragmentation issues:
1) Update your server (NetWare 6.0 or 6.5) to the latest NetWare Support Pack.
2) Limit the amount of cache TSAFA requests.
3) Set a hard limit on the amount of RAM that DS.NLM uses.
4) Set the File Cache Maximum Size parameter.
You should then reboot and run the server for a few days in normal operation, including automated back-up jobs. In a few instances, there may still be a fragmentation issue and the TID outlines a couple of steps to take in that situation.
It’s now a very useful document, which appears to incorporate ideas from the operating system, directory service and archive teams working together, rather than in ignorance of each other. That’s the way it used to work at Novell and hopefully this is a harbinger of better days ahead.
