Workstation File Caching with NetWare Client 32

Articles and Tips: article

Ian Stiles

01 May 1996

The file caching feature in NetWare Client 32 represents a major step forward for client caching. It eases network and server congestion, allowing more users access to network resources and improving performance of already existing applications. The Client 32 cache has several patents pending (and more to come). The cache has been extensively tested at Novell and various third-party sites to help ensure data integrity.

Cache Size

As a general rule, the larger the cache, the better the network file I/O performance. Under DOS and Windows 3.1, typical cache sizes for various amounts of RAM are shown in the table below.

Free memory at Client 32 load time	Resulting Client 32 cache size
0 KB to 384 KB	0 KB
384 KB to 6 MB	384 KB
6 MB to 8 MB	512 KB
8 MB to 12 MB	1.5 MB
12 MB to 16 MB	2 MB
16 MB to 20 MB	3 MB
20 MB to 24 MB	8 MB
24 MB +	50 %

Note: For Client 32 version 1.0, the memory used for its cache is statically allocated and is not shared with the system (Windows). A future version will share memory such that as Windows needs memory, cache memory will be given back, and vice versa.

Overriding the Default Cache Size

The default cache size may be configured by the user in the NET.CFG file as follows:

NETWARE DOS REQUESTER MAX CACHE SIZE = 4096 FILE CACHE LEVEL = 3

On the Max Cache Size line, the number is represented in kilobytes. The default for the File Cache Level is zero, meaning that Client 32 will auto-determine the cache size. The default level will probably be set to 3 in the future. The different levels mean:

0	No file caching (turn off the cache)
1	Use one 4KB cache block per file as read-ahead, write-behind cache.
2	Fully cache open files only as long as they are open.
3	Fully cache open and closed files, when reopened; if the file is detected to be the same, reuse original cache blocks (fastest option).
4	Write-through cache-wait until acknowledgement is recieved that data is written to disk (safest option).

Ensuring Data Integrity

File data that is being written to a network server is held in the client's workstation memory for a period of time after the application has reported that the file was saved. It's important not to turn the power off on the workstation until the data has actually been written. The file data will be written immediately to the network if the application closes the file or if the application is exited. This is done in order to reduce the chance of a user turning the machine off while data has not yet been committed to a network file.

The preferred way to ensure the file data has been written is to completely exit all applications that have written data and then exit Windows. If the user is willing to do this, there are a couple of options that can be turned on that will also increase network performance. With the same general directions for setting the cache size, use the following options that you place in the NET.CFG file under the NetWare DOS Requester heading:

Close Behind Ticks = 36

Delay Writes = ON

The "Close Behind Ticks" setting specifies how long the client will hold files open after they are closed, to optimize the case where applications frequently close and reopen the same file. The time is measured in ticks (36 in the above example is 2 seconds). This option takes effect regardless of the "File Cache Level" setting.

The "Delay Writes" option allows the write data to lag behind the application's Close File request. This allows the application to continue without having to wait for the data to be actually written to the network server, thereby improving apparent performance. When this option is on, the data is written in a "lazy" fashion (meaning 8KB of data are written every 1/18th of a second), so as to not bottleneck the server and disk channel. This option only takes effect if write operations are being cached.

Data Integrity of Cached Files After an Auto-reconnect

Consider the case where an application writes data to a network file. The file is cached at the client, is then written to the server, but is sitting in the server's cache memory when the server experiences a network fault. Normally, this data would be lost because the client received a successful acknowledgment from the write request and freed the cache block because it was no longer "dirty" or in use.

With Client 32, write data is held for a period of time after the acknowledged write so that if this condition occurs, the file will be auto-reconnected after the server comes back up and this data will be rewritten to the server's cache. While this method is not 100% reliable, there is a way to get 100% reliability for this case at the cost of file write I/O performance. This is accomplished by setting the "Auto Reconnect Level" in the NET.CFG file to 4 (the default is 3). Reconnection levels include the following settings to the Auto Reconnect Level = parameter in the NET.CFG file under the NetWare DOS Requester heading:

0	= No automatic reconnect capabilities
1	= Reconnect devices only (connections, drive mappings, printer port connections)
2	= Reconnect devices, plus read-only files
3	= Reconnect devices and read-only files, plus all files and file locks
4	= Reconnect devices and read-only files, all files and file locks, plus file writes (data recovery guarantee)
5	= All the above, plus switch to local disk for storage and resync files later (for NetWare Mobile)

Caching and Multiuser Databases

Database files are typically opened in a mode such that caching is not allowed. However, Client 32 has a new feature called "Opportunistic Locking." This option defaults to On and is only used when a file is opened and the server indicates that no one else is using the file. This allows the client to cache files that are not normally cached, thus greatly improving performance. If a second workstation attempts to open the same file, the server notifies the workstation and caching for the file is turned off.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.