Synchronous or asynchronous operations

AFM operations are serviced either synchronously or asynchronously. Reads and revalidations are synchronous operations, and update operations from the cache are asynchronous.

Synchronous operations require an application request to be blocked until the operation completes at the home cluster. File data is available while AFM queues are processed asynchronously in the background.

If synchronous operations depend on the results of one or more updates or asynchronous operations, AFM prioritizes the dependent asynchronous operations before the execution of the synchronous operations. For example, synchronous operations like file lookup cause dependent asynchronous operations to be flushed, overriding asynchronous delay (afmAsyncDelay).

AFM deploys a filtering algorithm for most optimal flushing performance by analyzing the queued requests. For example, if a write and a delete are in a queue on the same file, the write request is dropped from the queue and the delete is run at home. Similarly, when mkdir and rmdir of the same directory name are in a queue, both requests are dropped.

AFM sends data from cache to home as root. If home has fileset quotas at home, it must be set such that it can accommodate all writes from cache.

The afmRefreshAsync parameter changes the synchronous behavior. This parameter causes a readdir, which must be a synchronous command, to behave asynchronously. That is, like a follow-up readdir for an already cached directory. The Async readdir goes in the queue like any other asynchronous operation, where the cache serves existing readdir contents locally.

This afmRefreshAsync is useful for IW, RO, and non-dirty or unchanged LU modes that need to perform revalidations frequently with the home. The applications must not be affected with such a readdir on the application path.