Resync on SW filesets

A conflict situation might arise due to an inadvertent write on an SW home. AFM runs a resynchronization automatically.

Writing data on an SW home is not allowed under normal circumstances. However, AFM does not enforce this condition. If there is an inadvertent write or corruption at an SW home due to some error situation, it results in a conflict scenario for the single-writer fileset.

Note: Resync does not use parallel data transfers. Even if parallel data transfer is configured and the target is a mapping, the data transfers are not split.

If AFM detects inconsistencies during flushing, the fileset goes into NeedsResync state. When the fileset is in the NeedsResync state, AFM runs a resynchronization automatically during the next request to the primary gateway, and the inconsistencies are resolved.

If resync is not triggered automatically, the inconsistencies must be manually resolved by running the resync command. When you run a resync, the fileset must be in the Active or the NeedsResync state. Resync is not allowed on IW filesets as multiple cache filesets can update the same set of data. Use the following command - mmafmctl Device {resync | expire | unexpire} -j FilesetName. For more information, see mmafmctl command.

# mmafmctl fs1 resync -j sw1

          mmafmctl: Performing resync of fileset: sw1 

         # mmafmctl fs1 getstate -j sw1
         Fileset Name Fileset Target     Cache State Gateway Node Queue Length   Queue numExec
         ------------ --------------      ----------- ------------ ------------ -------------
         sw1    nfs://c26c3apv2/gpfs/homefs1/newdir1 Dirty      c26c2apv1    4067         10844

During a resync, all cached data and metadata are queued in the priority queue. The resync process is asynchronous and completes in the background. The callback event afmManualResyncComplete is triggered when the resync completes. When the priority queue is completely flushed, the fileset state changes to Active.

Evicted files are not synchronized to home.

A resync of partially cached files pushes only the cached data blocks to the new home. Uncached blocks are filled with null bytes.

Important: Do not use on an SW fileset, except when it is required to correct the home under such conflict scenarios.

Out-band Resync - You can choose to copy all cached data offline from the AFM cache to the new home with any tool that preserves modification time (mtime) with nanoseconds granularity. An example of such a tool is - rsync version 3.1.0 or later with protocol version 31. After the data is copied, you can run mmafmctl failover to compare mtime and filesize at home, and avoid queuing unnecessary data to home.

Resync neither deletes new files or directories that are created at the home nor new names that are given to files or directories at the home.

In some cases, a cache has pending changes such as delete and rename to replicate and the fileset recovery is triggered. In this case, the home might have old data and renamed files or directories are replicated to the home. Some extra files might exist at home because of the files or directories replication. The cache and the home have the latest copy of the files.