Workstation File Caching with Client32

Articles and Tips: tip

Ian Stiles

01 Jan 1996

The file caching feature in NetWare Client32 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 Client32 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 Windows 95, the cache size that is allocated is 25 percent of free memory after Windows 95 is loaded. Under DOS and Windows 3.1, typical cache sizes for various amounts of RAM are shown in the table below.

Figure 1:

Note: For Client32 version 1.0, the memory used for its cache is statically allocated and is not shared with the system. A future version will share memory with the system such that as Windows 95 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. Here are instructions for the two platforms.

DOS and Windows 3.1 Workstations. Add the following lines to the NET.CFG file:

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

Windows 95 Workstations. If you are in Windows 95, use the menu sequence Start -> Settings -> Control Panel -> Network. Highlight the Novell NetWare Client 32 component and then select Properties. From there, look for the keyword "Max Cache Size" and set that value to the desired cache size specified in kilobytes. To turn the cache off altogether, look for the keyword "File Cache Level" and set it to zero.

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:

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" to 4 (the default is 3).

These automatic reconnection levels have the following meanings:

0	No auto-reconnect support
1	Only auto-reconnect connections, drives, and printers
2	Auto-reconnect all except files that have been written to
3	Auto-reconnect all with best-guess rewrite of data after reconnection (default and fastest option)
4	Auto-reconnect all with guaranteed write data integrity across reconnection (very slow option for file write operations)

Caching and Multiuser Databases

Database files are typically opened in a mode such that caching is not allowed. However, Client32 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.