When a client requests data from the FlexCache volume, the data is read through the network from the origin system and cached on the FlexCache volume. Subsequent requests for that data are then served directly from the FlexCache volume. In this way, clients in remote locations are provided with direct access to cached data. This improves performance when data is accessed repeatedly, because after the first request, the data no longer has to travel across the network.
You must have the flex_cache license installed on the caching system before you can create FlexCache volumes. For more information about licensing, see the System Administration Guide.
A FlexCache volume must always be a FlexVol volume. FlexCache volumes can be created in the same aggregate as regular FlexVol volumes.
The origin volume can be a FlexVol volume or a traditional volume; it can also be a SnapLock volume. The origin volume cannot be a FlexCache volume itself, nor can it be a qtree.
The following objects can be cached in a FlexCache volume:
Note
In this document, the term file is used to refer to all of these object types.
When a data block from a specific file is requested from a FlexCache volume, then the attributes of that file are cached, and that file is considered to be cached. This is true even if not all of the data blocks that make up that file are present in the cache.
Cache consistency for FlexCache volumes is achieved using three primary techniques: delegations, attribute cache timeouts, and write operation proxy.
When data from a particular file is retrieved from the origin volume, the origin volume can give a delegation for that file to the caching volume. If that file is changed on the origin volume, whether from another caching volume or through direct client access, then the origin volume revokes the delegation for that file with all caching volumes that have that delegation. You can think of a delegation as a contract between the origin volume and the caching volume; as long as the caching volume has the delegation, the file has not changed.
Note
Delegations can cause a small performance decrease for writes to the origin volume, depending on the number of caching volumes holding delegations for the file being modified.
Delegations are not always used. The following list outlines situations when delegations cannot be used to guarantee that an object has not changed:
Delegations are not used for any objects other than regular files. Directories, symbolic links, and other objects have no delegations.
If connectivity is lost between the caching and origin systems, then delegations cannot be honored and must be considered to be revoked.
If the origin volume cannot store all of its delegations, it might revoke an existing delegation to make room for a new one.
When data is retrieved from the origin volume, the file that contains that data is considered valid in the FlexCache volume as long as a delegation exists for that file. However, if no delegation for the file exists, then it is considered valid for a specified length of time, called the attribute cache timeout. As long as a file is considered valid, if a client reads from that file and the requested data blocks are cached, the read request is fulfilled without any access to the origin volume.
If a client requests data from a file for which there are no delegations, and the attribute cache timeout has been exceeded, the FlexCache volume verifies that the attributes of the file have not changed on the origin system. Then one of the following actions is taken:
With attribute cache timeouts, clients can get stale data when the following conditions are true:
To prevent clients from ever getting stale data, you can set the attribute cache timeout to zero. However, this will negatively affect your caching performance, because then every data request for which there is no delegation causes an access to the origin system.
The attribute cache timeouts are determined by using volume options. The volume option names and default values are outlined in the following table.
For more information about modifying these options, see the na_vol(1) man page.
If the client modifies the file, that operation is proxied through to the origin system, and the file is ejected from the cache. This also changes the attributes of the file on the origin volume, so any other FlexCache volume that has that data cached will re-request the data once the attribute cache timeout is reached and a client requests that data.
When a client makes a read request, if the relevant block is cached in the FlexCache volume, the data is read directly from the FlexCache volume. This is called a cache hit. Cache hits are the result of a previous request.
A cache hit can be one of the following types:
The requested data is cached and no verify is required; the request is fulfilled locally and no access to the origin system is made.
The requested data is cached but the verification timeout has been exceeded, so the file attributes are verified against the origin system. No data is requested from the origin system.
If data is requested that is not currently on the FlexCache volume, or if that data has changed since it was cached, the caching system loads the data from the origin system and then returns it to the requesting client. This is called a cache miss.
A cache miss can be one of the following types:
The requested data is not in the cache; it is read from the origin system and cached.
The requested data is cached, but the file attributes have changed since the file was cached; the file is ejected from the cache and the requested data is read from the origin system and cached.
There are certain limitations of the FlexCache feature, for both the caching volume and for the origin volume.
You cannot use the following capabilities on FlexCache volumes (these limitations do not apply to the origin volumes):
You cannot perform the following operations on a FlexCache origin volume or storage system without rendering all FlexCache volumes backed by that origin volume unusable:
If you want to perform these operations on the origin volume, you can delete all FlexCache volumes backed by that volume, perform the operation, and then recreate the FlexCache volumes.
Note
You can use SnapMover (vfiler migrate) to migrate an origin volume without having to recreate any FlexCache volumes backed by that volume.
If you want to perform a snapmirror migrate operation to a FlexCache origin volume, you must delete and recreate all FlexCache volumes backed by that volume after the migrate operation completes.
If you must change the IP address of the origin system, you can delete all FlexCache volumes backed by the volumes on that system, change the IP address, then recreate the FlexCache volumes.
If connectivity between the caching and origin systems is lost after a FlexCache volume is created, any data access that does not require access to the origin system succeeds. However, any operation that requires access to the origin volume, either because the requested data is not cached or because its attribute cache timeout has been exceeded, hangs until connectivity is reestablished.
Copyright © 1994-2005, Network Appliance, Inc. All rights
reserved.
Part No. 210-01085_B0
File: 6vol22.htm
Last updated: 01-Dec-2005 16:51:37