- Windows File Systems
- Windows NTFS
- Windows ReFS
- Windows DFS
- Storage Spaces Direct
- Storage Replica
- Storage QoS
- Volume Shadowcopy Services
- Windows Volume Mgmt.
- Windows System state
- Removable Storage System
Unfortunately, Novell Netware is pretty much dead as an operating system. These pages will not be updated anymore, but will be retained for a while for the benefit of the faithful who continue to use this excellent operating system.
Novell did create the Open Enterprise Server, a SUSE Linux based OS that runs most of the old NetWare server functions.
The older Netware file system is usually called the Traditional File System. It has been superseded by the Novell Storage Services (NSS) system. Other supported file systems include NFS for UNIX support, and the Common Internet File System (CIFS).
The traditional NetWare file system provides a lot of the performance-enhancing features that you often see in disk subsystems. Examples are Elevator seeking (described at the end of the SATA page), background writes and file compression.
When you set up a Netware file system you define the allocation blocksize. If you make it too big, then small files waste a lot of space. If you make it too small, performance suffers. The smallest blocksize is 4k and the largest is 64k. The traditional NetWare file system uses a technique called 'Block Suballocation' which allows small files to share a single block to use space efficiently.
Some of the advantages of NSS over the traditional file system are -
NSS requires a number of NLMs most of which are loaded by default in Netware 6.5. The principle NLM is NSS.NLM. To find out what NLMs are running on your system, use the console command
To get a list just the loaded NLMs starting with NSS.
TSAFS.NLM is used to control access to the Netware file system. TSAFS has a number of parameters that you can adjust to tune the file system performance. To see what the TSAFS options are, type 'tsafs' at the server console and you will see a listing of all the TSAFS options, their current value, and range or permissible values. You can edit these values in the file SYS:/ETC/SMS/TSA.cfg, but you will need reload TSAFS for them to take effect.
If you install NSS, then you should not mix it with any other file system as this will cause performance problems due to the way NSS uses cache.
While the traditional NetWare file system was pretty much supplied as is, you can do some performance tuning with the NSS file system. It would seem that NSS as supplied in NetWare 6 comes pre-configured for a 100-user environment and those parameters will not be appropriate for a large environment. Of course, the first thing you need to do is to have a look at the system and see if it needs tuning at all. I'm a firm advocate of the philosophy which says 'if it is not broken, do not touch it'. You can get Volume Inventory and real time monitoring information as described in the Netware Storage Statistics page.
NSS gets a lot of its performance benefits by using cache to assist with disk IO. You can query the effectiveness of this cache by using a couple of cache monitoring commands. However the results of these commands are averaged over the time since the last time the server was booted, so if you want a recent view, you may want to reset the statistics. You do this with the server console command
NSS / ResetStats
but you will have to wait a few days to get a reasonable data sample, before the refreshed statistics become useful.
To get information on file system cache hits and misses use the command
NSS / CacheStats or /Cache
An example of the output from this command is
You should normally expect to see a cache hit rate of about 98%. In the example above, the user cache hit rate looks like a problem, as it is just 42%, but that server has just completed a backup, so 42% is acceptable at that time.
The NSS Name Cache is used to prestage data for file or directory searches.
You can increase the size of the name cache by updating the /NameCacheSize parameter, but be aware that this might not improve directory search
performance as Netware does not store all NSS directory information in the name cache. The num victim selects parameter value above appears to be high. This indicates that NSS is having to flush a lot of old data from the name cache to make room for new entries. This may indicate that the name cache size should be increased. The cache hit percentage is also a little low at 90%, ideally it should be higher than that.
A positive cache hit indicates that a file was found and the file name was cached. A negative cache hit indicates that a file was not found, and the file name stored with the information that it does not exist.
The STATUS command will give you information about NSS configuration parameters.
Example output is
NSS tuning is no different to any other tuning. You can work out what you think parameters ought to be based on server usage and existing performance statistics, but eventually you have to make changes and see what effect they have. It is best to change one or at most two parameters at once, then see what affect they have, rather than making a lot of changes at once. You should also start with an up to date installation with all current patches applied.
Be aware that you if you try to give NSS more cache than the server has memory available, then NSS will not load up. While adding more server RAM is usually a good idea, NSS cannot use more than 4 GB.
You can change NSS parameters issuing commands from the server console window, or by adding them into a file called c:NWSERVER\NSSSTART.CFG then rebooting the server.
You prefix the NSS parameters by NSS, then add the new parameters. You can specify more than one parameter in a command, for example
NSS /NameCache=20000 /MinBufferCacheSize=1024
|Parameter||Default value||Allowed values||Comment|
|/CacheUserMaxPercent||70%||1-99||controls the split between system and user cache.|
|/CacheBalance||60%||1-99||controls the system cache percentage on cache reset|
|/MinBufferCacheSize||512||256-1,048,576||minimum amount of reserved system cache|
|/MinOSBufferCacheSize||256||256-1,048,576||Minimum memory reserved for system use|
|/CacheBalanceMaxBuffersPerSession||1024||16-1,048,576||the amount by which the system cache is changed at each balance session|
|/NameCache||2111||3-65,521||the number of cached name trees|
|/OpenFileHashShift||15||8-25||the number of hash table entries for open files. The number is powers of 2, so the default is 2**15|
|/ClosedFileCacheSize||50,000||16-1,000,000||the amount of cache reserved for closed file information|
|/nodatashredding=volumename||N/A||N/A||data shredding will totally overwrite purged files, but with a performance overhead. This parameter suppresses data shredding for a given volume|
|/AllocAheadBlks||15||0-63||The number of blocks that NSS will pre-allocate when creating a file. Reduce this number if you write a lot of small files/|
|/NumWorkToDos||50||5-100||The number of concurrent work threads|
|/FileFlushTimer||10||1-3,600||The number of seconds modified data is kept in cache before it is written to disk|
|/BufferFlushTimer||1||1-3,600||The number of seconds a modified buffer is kept in cache before it is flushed to disk|
Distributed File Services comes installed with NetWare 6, and basically provides access to remote volumes. This junctioning process allows volumes to be joined together so that they appear as subdirectories in a file system. A junction is simply a virtual directory that is assigned a dummy filename within a file system. When you access that dummy filename, you are redirected to a file system located at the root of another NetWare volume. See the DFS page in the Windows section for more details of how this works.
Junctions have to be created by administrators, the users do not have the access to create them. At present, you can only create DFS junctions on NetWare 6 NSS volumes; however, those junctions can point to either NetWare 5.1 NSS or traditional volumes. The junctions must point to volumes that are within the same NDS tree. Creating a junction will not automatically create access rights to the target volume. These are still controlled by normal rights assigned to that user on that volume. If the user has access rights, then he will simply see the junction as a new subdirectory, and will be able to access the entire volume as if it was a subdirectory.
Junctions are managed by the Volume Location Database (VLDB). Each junction has a unique ID, which is automatically stored in both the VLDB and in the corresponding NDS Volume object.
You have to use ConsoleOne to create or delete junctions, but before you can begin to create an actual junction, you must create at least one DFS Management Context at an O or OU level in the NDS tree. When you create a Management Context, you specify which servers will run the VLDB Management Service and hold the actual database.
When you activate DFS, you create the following files in SYS:ETC:
You also create a hidden, read-only file called ~DFSINFO.8-P on each NetWare volume.
Do not modify or delete any of these four files. If you accidentally delete any of these files, you must rebuild the VLDB from the VLDB Management Service.
NetWare NFS is designed to allow data sharing and common administration between Netware and UNIX file systems. NFS is based on the Sun Network File System, and has three components.
NFS Services or Network Information Services (NIS) is the administrative component of NFS, while NFS Gateway and NFS Server are its file-sharing components.
NFS Services provides transparent, bidirectional file sharing, enabling both NetWare and UNIX clients to use the same commands and interfaces to access files. No additional hardware or software is required on either the NetWare or UNIX client workstations. It also includes a File Transfer Protocol (FTP) server and gateway that allows FTP clients to transfer files from IBM hosts. NFS fully supports NSS volumes.
NFS Services uses NDS or eDirectory to control access to NetWare data. UNIX clients can continue to use their own access security, or they can integrate with NDS.