Delegations

You can think of a delegation as a contract between the origin system and the caching volume; as long as the caching volume has the delegation, the file has not changed. Delegations are used only in certain situations.

When data from a file is retrieved from the origin volume, the origin system can give a delegation for that file to the caching volume. Before that file is modified on the origin volume, whether due to a request from another caching volume or due to direct client access, the origin system revokes the delegation for that file from all caching volumes that have that delegation.

Delegations are not always used. The following list outlines situations when delegations cannot be used to guarantee that an object has not changed:

Objects other than regular files
Directories, symbolic links, and other objects that are not regular files have no delegations.
Origin volumes that are SnapMirror destinations
If the origin volume is a SnapMirror destination, delegations are not used.
When connectivity is lost
If connectivity is lost between the caching and origin systems, then delegations cannot be honored and must be considered to be revoked.
When the maximum number of delegations has been reached
If the origin volume cannot store all of its delegations, it might revoke an existing delegation to make room for a new one.

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.

If a FlexCache volume is taken offline, all its delegations are destroyed.

Parent topic: How cache consistency is achieved