Client-side cache (QNX)
Csc [options...] [prefix...] &
Format: | Meaning: |
---|---|
n | (n kilobytes) |
nM or nm | (n megabytes) |
nK or nk | (n kilobytes) |
Run with 3 megabytes of cache:
Csc -c 3M &
Run with 1 megabyte of cache, include only the files under /usr and /local, and exclude a set of database files:
Csc -c 1024 -e "/local/database/*" /usr /local &
Run with the configuration stored in /etc/config/Csc.3:
Csc -F /etc/config/Csc.3
The pattern-matching mechanism used by Csc differs from the one used by the Shell. Thus the * in the second example will match all files in the /usr and /local directories as well as all files in their subdirectories (e.g. /usr/bin). Likewise, the * in the third example will match all the .h files in /usr/include as well as all the .h files in its subdirectories.
The client-side cache (Csc) implements local caching on a network workstation (i.e. on the client side of a network connection). Csc learns your working set of utilities, source files, data files, and so on, and keeps them up-to-date in local cache. Whenever you use a file, Csc verifies it has the most current version and then updates the cache, if necessary. Thus you gain the performance advantage of a ramdisk without incurring any of the file version problems possible with a ramdisk. For example, if you're programming on a workstation, Csc will speed up your edit/compile/debug cycle but won't interfere with updates to your source files, headers, and development tools.
All file reading goes through Csc, which caches the data read. If a file is reread, the data will be returned from cache, thus saving the time that would otherwise be spent going across the network. Csc implements a sparse cache, so only the accessed portions of a file are actually placed in the cache (this is especially useful when working with link library files).
Csc supports only files opened for read-only; if a file is opened for read/write or write-only, the I/O requests go directly to the filesystem.
Csc verifies a cached file only when the file is opened or when a stat function is called (e.g. when ls is run). This may result in cache inconsistencies for files that are frequently updated (e.g. database files). To avoid this potential problem, either use -e to exclude frequently updated files or have all programs open such files for read/write. Either way, Csc will be bypassed and the data won't be cached.
The -F config_file option can be used to specify a configuration file which defines the command-line parameters Csc is to use. If -F is not specified, the default configuration file (/etc/config/Csc) will be used. When -F is specified, the named configuration file will be read first, then the default configuration file will be read (possibly overriding the first configuration file). When a configuration file is specified it is typically named /etc/config/Csc.nodeid, where nodeid is the node ID of the node Csc is being started on. The configuration files contain what are essentially command-line parameters to Csc, one parameter per line. For example:
-c10M -e/usr/spool/* -e/etc/licenses/* /bin /etc /usr /home /etc/config
You need to start the Pipe Manager (Pipe) before you run Csc.