Lascon StorageCookie PolicyContact usSearch this Site

HOME
Backups

CLOSE







Hardware

CLOSE







Mainframe

CLOSE






Windows

CLOSE





Databases

CLOSE




 

Strategy

CLOSE



Click on the grey buttons above to open an overlay menu that shows the areas in each major section.
Click on the yellow buttons to the right to move between pages in this area.

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. Netware was eventually bought out by Micro Focus who continue to
support some Netware facilities on the Linux based Open Enterprise Server 2018

NETWARE FILE SYSTEMS

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).

Traditional File System

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.

Novell Storage Services

Some of the advantages of NSS over the traditional file system are -

 NSS stores objects on disk in balanced trees to improve system performance. Novell claim
that this guarantees the system can retrieve an object from the disk in no more than four I/O
cycles and that the system can locate an object anywhere in storage without loading the
entire directory entry table into memory. This means that NSS requires less memory to mount
compared to the traditional file system; as little as 4 to 10 megabytes.
 NSS can handle bigger objects, and a lot more objects than the traditional file system. NSS
uses 64-bit interfaces and can to store up to 8 terabytes of data.
 NSS maintains a journal that records all transactions written to disk and all transactions
waiting to be written. This means that volumes can be remounted quickly after a crash, as
NSS just uses the journal to complete or backout a transaction. The traditional file system had
to use the VRepair utility to scan the directory entry tables, which took several minutes.

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
MODULES
or
MODULES NSS*

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.

NSS Tuning

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.

NSS /NameCacheStats

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.

NSS /Status

Example output is

Performance Tuning Parameters

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

Default Allowed
Parameter Comment
value values
/CacheUserMaxPercent 70% 1-99 controls the split between system and user cache.
/CacheBalance 60% 1-99 controls the system cache percentage on cache reset
256-
/MinBufferCacheSize 512 minimum amount of reserved system cache
1,048,576
256-
/MinOSBufferCacheSize 256 Minimum memory reserved for system use
1,048,576
/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
the number of hash table entries for open files. The number is powers of
/OpenFileHashShift 15 8-25
2, so the default is 2**15
/ClosedFileCacheSize 50,000 16-1,000,000 the amount of cache reserved for closed file information
data shredding will totally overwrite purged files, but with a performance
/nodatashredding=volumename N/A N/A
overhead. This parameter suppresses data shredding for a given volume
The number of blocks that NSS will pre-allocate when creating a file.
/AllocAheadBlks 15 0-63
Reduce this number if you write a lot of small files/
/NumWorkToDos 50 5-100 The number of concurrent work threads
The number of seconds modified data is kept in cache before it is written
/FileFlushTimer 10 1-3,600
to disk
The number of seconds a modified buffer is kept in cache before it is
/BufferFlushTimer 1 1-3,600
flushed to disk
/AuthCacheSize 1024 15-50,000  

Distributed File Services

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:

 VLDB.DAT
 VLDBCFG.DAT
 VLRPR.LOG
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.

Network File System

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.

back to top

Windows Storage

Infrastructure

 Storage Spaces Direct

 Windows Volume Mgmt.
 Windows File Systems
 Deduplication
 Volume Shadowcopy Services
 Storage Replica

Management

 Windows System state

 Storage QoS
 Data Classification
 Defragmentation

Removed Features

 Removable Storage System

Novell Netware
  File Systems
 Disks and Volumes
 NDS and eDirectory
 Clustered Servers
 iFolder
 Netware Volume Statistics

Lascon updTES

I retired 2 years ago, and so I'm out of touch with the latest in the data storage world. The Lascon site
has not been updated since July 2021, and probably will not get updated very much again. The site
hosting is paid up until early 2023 when it will almost certainly disappear.
Lascon Storage was conceived in 2000, and technology has changed massively over those 22 years.
It's been fun, but I guess it's time to call it a day. Thanks to all my readers in that time. I hope you
managed to find something useful in there.
All the best

HOME
Backups

CLOSE







Hardware

CLOSE







Mainframe

CLOSE





 Windows

CLOSE





Databases

CLOSE






Strategy

CLOSE



Click on the grey buttons above to open an overlay menu that shows the areas in each major section.
Click on the yellow buttons to the right to move between pages in this area.

DISCLAIMER - By entering and using this site, you accept the conditions and limitations of use

Click here to see the Full Site Index       Click here to see the Cookie Policy       Click here to see
the Privacy Policy                             ©2019 and later, A.J.Armstrong