[Editor's note: The From the Field column is brought to you by Lotus Support, and features technical articles based on our experiences with helping customers to find solutions in the field. This month's article focuses on a customer solution for managing the size of the CACHE.DSK file when serving the Notes client from a network file server.]
When it comes to running the Notes client, you essentially have two choices: (1) run the client from the local hard drive or (2) serve the client to users from a network file server. The method you choose is largely based on personal preference rather than technical considerations. However, if you plan to serve the Notes client, you need to carefully consider the location of Notes' personal data files, such as NAMES.NSF, DESKTOP.DSK, and the CACHE.DSK. The reason is that the location of these personal data files can have a dramatic effect on file server disk-space consumption and overall client performance. In particular, one user's CACHE.DSK file may grow to as much as 20MB. (The CACHE.DSK file contains design elements of server-based databases and cross-replica journaling information.) One customer learned how to control the size of the CACHE.DSK files, as you'll see, in this report From the Field.
A look at the customer's network setup
The customer selected for this report serves the Notes client to approximately 1,000 users in an interesting network environment. The networking operating system is OS/2 Warp Server 3.0 (a.k.a. LAN Server 5.0) with a total of 15 servers. One of these servers is a domain server that handles logon and user security. The next one is a corporate data server, which is a sort of dumping ground for general data. The next three are dedicated application servers. Three more after that are dedicated user data servers. The seven remaining machines are dedicated print servers.
The network topology that supports this environment is 16 Mbps Token Ring from the desktop computer back to the Multistation Access Units (MAU's). There are approximately 10 rings connected via an Asynchronous Transfer Mode (ATM) backbone.
The standard desktop configuration is a Pentium 133MHz-based computer, with 1GB of disk space, 16MB of RAM, an SVGA graphics card, and a supporting 15" monitor. Despite this capable desktop configuration, all applications, including the operating system, are served to users from network file servers. The only things loaded locally on each desktop computer are a copy of DOS 6.22, IBM Local Area Networking Support version 1.38, and DOS LAN Requester level 7066.
The customer serves Windows 3.1 and all desktop applications from network file servers dedicated to serving applications. All the personal files for program execution, environment configuration, and personal data files are stored in the user's personal data directory on one of the three network file servers dedicated to user data storage. This configuration allows users to have the same operating system and application setup on any computer in the company. Users can walk up to any available computer, log onto the LAN, and have their entire personalized configuration served to them.
Serving the Notes client
Now, when it comes to the Notes client, the customer needed to install and deploy the client in a way that conformed to this established network setup. As most of you already know, the Notes client is easy to install in such an environment.
The first level of the Notes application directory (usually C:\NOTES) contains all the program files. When you place this directory on a shared network drive, everyone can run the client from the same set of files (in other words, one installation serves many). The next level of the Notes application directory (usually C:\NOTES\DATA) contains the individual user files. Therefore, users just need their own Notes data directory to run a personalized copy of Notes.
To set this up, the customer split the Notes client into shared program files and personal data files by doing a standard local installation. Then, they copied the program files from the Notes directory to a network file server, and set the user rights to this directory to Read and Execute.
In order to distribute the individual data files (such as NAMES.NSF and DESKTOP.DSK), the customer first needed to modify the NOTES.INI file that was created during the initial local installation. In particular, they needed to change the NOTES.INI settings that referenced a local drive and directory to correctly reference the network drive and directory location. These changes are shown below:
- Directory=U:\NOTES\DATA
- WinIconPath=U:\NOTES\DATA\WIN
- FileDlgDirectory=U:\
- Spell_Dir=F:\NOTES45\DATA
Note: The "U" drive maps to the network file server location for a user's personal data directory, and drive "F" maps to the network file server location for all served applications.
Then, the customer distributed the individual data files and required Windows dynamic link library (DLL) files by using a program called WinInstall. This program facilitates the creation of scripted program installations; users select the program they want to install, and WinInstall takes care of the rest. Although they could have easily done a similiar type of installation using Notes, the customer elected not to use this approach because they wanted to be consistent with how their other network applications were distributed. (For information on how to use Notes to create a network distribution of the client, see the Domino 4.6.1 Administration Help).
Managing disk space consumption: the CACHE.DSK challenge
After customizing their Notes client installation through NOTES.INI settings and sharing of the program code, the customer ran into another issue in their quest to conserve file server disk space. During the pilot phase of their Notes client rollout, they discovered that each user's data directory was growing well beyond an acceptable size. The customer carefully examined the contents of each directory and noticed that the reason for the excessive growth was the CACHE.DSK file.
The CACHE.DSK file first became available in Release 4. This special file contains design elements of server-based databases and cross-replica journaling information. Storing these items in this file helps improve client performance when accessing databases located on the server and automates the process of read-mark synchronization.
In the customer's environment, the size of the CACHE.DSK file varied from 2 to 20MB. Since the pilot group was small, the impact on disk-space consumption was minimal; however, the official Notes rollout would involve 1,000 users consuming an estimated 2 to 20GB of disk space with just one file. The customer's LAN infrastructure wasn't capable of handling such an extensive utilization of disk space, and thus, they needed to control the size of the CACHE.DSK files.
Understanding the CACHE.DSK file
The CACHE.DSK file serves a particular purpose for the Notes client. Attempting to control the size of this file may have a negative effect. Therefore, before looking at what the customer did to control this file, we need to gain a deeper understanding of the CACHE.DSK to completely appreciate the selected method of control.
Part of the CACHE.DSK file's function is the storage of cross-replica journaling information. This information helps automate the process of read-mark synchronization. Each database, and database replica, that a user accesses has its own set of read marks stored in the database. Therefore, documents marked as "read" in a replica copy of a database may not have the same status in the server copy of that database. In order for the read marks in a database replica and the replica's source to be the same, a process of synchronization must take place.
Note: In situations in which a database exists on read-only media, such as on a CD-ROM, unread marks are stored in the DESKTOP.DSK file.
In Release 3, users could synchronize read marks using of an option from the Tools menu. Although this option was easy to use, users had to make a conscious decision to start the synchronization process. Release 4 did away with this manual process and made read-mark synchronization automatic.
Cross-replica journaling information accounts for only 500KB of the CACHE.DSK file size. The rest of the file's size is used for the storage of database design elements.
Design elements, such as forms and subforms, of databases located on the server account for the majority of the size of the CACHE.DSK file. Because recently used forms and subforms are stored locally in the CACHE.DSK, client performance is enhanced. For example, if a user opens the client profile for Acme Widgets in a Notes database located on the server, the client profile form and the Acme Widget data is sent to the user. Now, if that user then opens the client profile for XYS Corporation, the locally cached client profile form is used and only the information about XYS Corporation is sent to the user. Thus, client performance improvement becomes quite obvious.
Aside from the actual purpose of the CACHE.DSK, there are a few additional points worth mentioning:
- The CACHE.DSK is created automatically whenever Notes starts, if the file doesn't already exist. Therefore, if you delete this file, Notes will recreate it the next time the client is started.
- The CACHE.DSK is actually a Notes database with no built-in forms or views. Therefore, you can compact this file to recover unused space. To do this, right-click on any part of the Notes workspace, choose Workspace Properties from the pop-up menu, select the Information (i) tab and click Compact. Note that compacting the CACHE.DSK in this manner also compacts the DESKTOP.DSK. Also, the value in the Size field that appears on the Information tab reflects the combined size of the CACHE.DSK and the DESKTOP.DSK.
- The CACHE.DSK, by default, is located in the Notes data directory. There are, however, two methods for relocating the file: the database redirection file and a NOTES.INI redirection parameter.
Managing users' CACHE.DSK files: The solution
To handle the growth issue of the CACHE.DSK, the customer had three options from which to choose:
Option #1: Add instructions to the network logon script to delete the CACHE.DSK each time the user logs onto the network.
The customer's LAN environment executes a logon script each time a user enters the network environment. This script performs such functions as drive mapping and printer queue assignment. Adding instructions to this script to delete the CACHE.DSK file would be simple. This instruction would cause the CACHE.DSK to be deleted each time a user logged onto the network. Then, whenever the user started the Notes client, it would automatically create a new CACHE.DSK file.
There are two problems with this option. First, deleting the CACHE.DSK file also deletes any cross-replica journaling information that might be stored in that file. As long as users work only with databases located on a single Domino server, there is no problem; however, there is no guarantee that some users won't use locally stored replica copies or the same database on different Domino servers. The other problem with this option is that it doesn't actually resolve the disk-space consumption issue. Regularly deleting the CACHE.DSK helps keep its overall size in check, but the file is still residing on a network file server consuming disk space.
Option #2: Limit the size of the CACHE.DSK by compacting it on the workspace.
As we explained earlier, you can control the overall size of the CACHE.DSK by right-clicking on the Notes workspace, choosing Workspace Properties, and selecting the Information (i) tab. Before clicking Compact, you can select the maximum size for the file by modifying the "Use no more than x MB locally for server based design elements such as forms and subforms" field. This field controls the amount of space that design elements can consume in the CACHE.DSK (space taken up by cross-replica journaling information is not controlled by this setting). The default is 5MB.
Although this approach appears to be the one the customer is looking for, there are three important drawbacks. First, the lowest value possible for the maximum size is 1MB. For a couple of users, this 1MB value isn't that bad; however, multiply 1MB by 1,000 and the size is still an issue. The second drawback is that this maximum size value is stored in the CACHE.DSK file. If this file is deleted, Notes creates a new CACHE.DSK with the default maximum size of 5MB. Finally, the biggest drawback has nothing to do with limiting the size of the file and everything to do with where this file is located -- the CACHE.DSK is still sitting on a network file server. One of the purposes of the CACHE.DSK is to speed up client performance by locally storing forms and subforms. When this file is sitting on a network file server, the client doesn't realize its entire performance benefit. What's the point of a cache if you must travel across a network to use it?
Option #3: Redirect the CACHE.DSK file using a NOTES.INI redirection setting (available in Release 4.5.2 and later) or a database file pointer.
The best solution for the customer's situation is one that controls file server disk-space consumption while also allowing users to realize the performance benefit of caching forms and subforms. This type of solution is possible by redirecting the CACHE.DSK to a local disk drive. There are two ways to set up this redirection.
The first way to redirect the CACHE.DSK from its default location of the Notes data directory is to add the CACHE setting to the NOTES.INI file. Release 4.5.2 introduced this setting, which you can add anywhere in the NOTES.INI file. The CACHE setting requires only the complete path and file name for the new CACHE.DSK location (for example, CACHE=C:\TEMP\CACHE.DSK).
The other way to redirect the CACHE.DSK file is intended for any release prior to 4.5.2. This approach requires that you first copy the existing CACHE.DSK to its ultimate destination (for example, C:\TEMP\CACHE.DSK). Then, you can create a small text file with the complete path and file name for the CACHE.DSK (for example, C:\TEMP\CACHE.DSK), and then place the new file in the Notes data directory. This approach works the same way as a database redirection file.
The recommended method of redirection is to use the NOTES.INI setting. This approach does not require that the file exist in the location specified in the NOTES.INI. If Notes fails to find the file in the specified location, it automatically creates a new CACHE.DSK in the specified location. The second approach, however, requires the CACHE.DSK to exist in the redirected location to work successfully. If the file is accidentally deleted, Notes creates a new CACHE.DSK in the Notes data directory and overwrites the existing redirection text file.
The selected option
At one time or another, the customer tried to implement all three options. Finally they settled on Option #3. When this decision was made, the customer was using Release 4.5. To use the NOTES.INI CACHE setting, they needed to upgrade to Release 4.5.2. Because they were serving the Notes client, they needed to upgrade only one instance of the client program files. After upgrading the client, they sent a simple mail message to current users. This message included a simple button that added the appropriate CACHE setting to the user's NOTES.INI file. After everyone received this message, a simple batch program was launched late one night, prior to the nightly backup. This batch file deleted every instance of the CACHE.DSK from the network file servers. Now, file server disk-space consumption is under control, and users are realizing the performance benefits of the CACHE.DSK.