Those familiar with NetWare 3.x file systems are aware of the way Novell organizes their volumes into blocks. A file that is larger than the disk block size will need multiple disk blocks to hold the entire file and only one file, or part thereof, can exist is a specific block. This presents an issue with wasted disk space. For example, if we have a block size of 4K on our SYS volume and we have a file that is 5K we will use two 4K blocks to store the entire file which uses a total of 8K of disk space. In this example 3K or 38 percent of the 8K allocated is wasted.
Related to this issue is that under NetWare the larger the block size the more can be written to the disk at one time. Therefore information is written faster to the disk with a larger block size. For example, a file that is 25K will take 7 writes with a 4K block size and only 2 writes with a 16K block size. The bigger the block size, the faster the writes and more disk space wasted. This issue was addressed in NetWare 4.x.
Disk Block Suballocation is a disk storage optimization technique new to NetWare 4.x that is designed to address these issues. Suballocation modifies the traditional NetWare disk blocks allowing us to accomplish the following:
First, it allows us to sub-divide a block into smaller units. A 64K block can be divided into (2) 32K units, (4) 16K, (8) 8K, etc., down to (128) 512 byte units. This means with the default block size of 64K, a file that is 65K we will be written to one 64K block and one 64K block that has been suballocated into (64) 1K units. The remaining (63) 1K units will be used by other files that need a 1K unit to complete the file write.
Second, it allows us to increase our block size to 64K without wasting massive disk space. In the example above the same file under NetWare 3.x, with a 64K block size, would have taken 128K instead of the 65K under 4.x with suballocation enabled. Having a block size of 64K will allow us to make fewer IO requests which increases performance.
Third, by using a larger block size we keep fewer entries in the FAT (File Allocation Table). This saves disk space as well as decreasing the amount of memory needed to mount volumes. The less memory needed to mount volumes, the faster they will mount.
For additional information regarding suballocation refer to Novell's June 1994 Appnote, "Compression and Suballocation in NetWare 4"
What support issues has Novell seen with Disk Suballocation?
There have been some problems with file server hangs and high utilization that were a result of suballocation problems. These problems have been fixed with patches that are contained in the 410 patch kits. Always apply ALL the current released patches.
There are additional issues that have caused high utilization that can be avoided by proper management of disk space and free blocks. Here are the issues and how they can be avoided:
Suballocation "thrashing" caused by lack of disk space. We have seen several customers who are having high utilization problems that have been caused by lack of disk space. Suballocation is a low-priority thread. This means, under normal conditions, that it only runs when the processor is idle. This condition of suballocation is a "non-aggressive" mode. When disk space is low, less than 10% available, we have seen suballocation go into an "aggressive" mode. In this state suballocation is bumped up to a regular priority thread and can take control of the volume semaphore until it has cleaned up and freed as much space as possible. This locking of the volume semaphore causes other processes, which are trying to use the volume, to wait until the semaphore is released. In large installations this results in an increase of Packet Receive Buffers and File Service Processes. When the Packet Receive Buffers max out the server will start dropping connections and users are not able to login. When suballocation completes its cleanup the semaphore will be released and the processes on the queue will be serviced. This will result in a utilization drop and the server will return to normal operation.
Suballocation "thrashing" caused by lack of free blocks. The lack of free blocks has also caused high utilization problems for the same reasons listed above. Lack of free blocks is different than lack of disk space. When files are deleted they are kept in a "deleted" state. This means the file actually exists but is not viewable to the user and does not show up in volume statistics as used space. The number of free blocks is determined by the following formula:
Free Blocks = [Total Blocks - (Blocks In Use by Files + Blocks In Use by Deleted Files)]
We have had several customers who look at their volume and it shows 50% of the disk available but there are no free blocks. These blocks are in use by deleted files. Running a PURGE /ALL from the ROOT of the volume has solved the problem. This issue will be addressed in future releases of NetWare 4.x.
What does Novell recommend when Disk Suballocation is enabled?
1. Load ALL the current released patches - The OS patches fix known problems with suballocation and other NetWare functions. These patches have been tested and are recommended by Novell Engineering.
2. Use a disk block size of 64K on all volumes where suballocation is enabled - This is the default block size for 4.x. This is the fastest and most efficient block size for volumes with suballocation enabled.
3. Keep 10%-20% of the volume space free to avoid the suballocation "Aggressive" mode - Disk space management is essential to avoid problems with suballocation. Make sure there is always 10%-20% available disk space on all volumes. This can be monitored my SERVMAN.NLM, NWADMIN.EXE or NDIR /VOL. If you are running low on disk space you need to either delete unneeded files or add additional disk space to the volume.
4. Maintain a minimum of 1000 free blocks on each NetWare volume that has suballocation enabled - Suballocation uses free blocks to perform its function. When free blocks are low suballocation could go into "aggressive" mode, lock the volume and cause high utilization. Maintaining over 1000 free blocks will avoid this problem in most cases. If there are not at least 1000 free blocks on the volume, run a PURGE /ALL from the root of the volume. This will free the "freeable limbo blocks" and move them back to "free blocks".
5. Set PURGE flag on all directories that have large amounts of temporary files created - Every temporary file that is created will be put on the "deleted file list". These files are kept on the disk until a PURGE is run. In order to avoid disk space and free block problems, you need to set the PURGE flag on specific directories that create large numbers of temporary files. Also setting IMMEDIATE PURGE OF DELETED FILES=ON will avoid this problem..