SnapVault stuck in quiescing state

[borismekler]

I have a FAS2040 (8.1.2P4 7-mode) replicating to vFiler on another FAS2040 (8.1.3 7-mode) using SnapVault, with a total of four relationships on three volumes. After rebooting the destination filer, three out of four relationships on the destination are stuck in 'Quiescing' state, and transfer attempts throw an error into console that it cannot connect to the source filer. One relationship works fine (incidentally, it's the smallest qtree, contains just a public folder database for an Exchange server), so networking is not the culprit. I tried waiting, but it's been three weeks with no change. On the source side, the same relationships are showing as 'Idle'. Rebooting the destination again doesn't help. Cannot offline or restrict the affected volumes, even if I stop the owning vfiler. Trying to run snapvault abort on the destination path says that it's already idle. Anything else I can do?

[richard_mackerras]

Hi,

Did you fix this?

Richard

[richard_mackerras]

Hi,

I have to conclude that the status "quiescing" is a red herring. snapvault doesn't do "quiescing" so far as I can see. Snapmirror does.

We had too many snapshots in the destination volume. 255 is the maximum number. So the snapmirror log file reported:

tgt Mon Jan 5 08:50:37 GMT staged_data create: Target_start
dst Mon Jan 5 08:50:57 GMT toaster:/vol/staged_data/staged_data toaster:/vol/staged_data/staged_data Coalesce_start (toaster(0151744715)_staged_data-base.1)
dst Mon Jan 5 08:50:57 GMT toaster:/vol/staged_data/staged_data toaster:/vol/staged_data/staged_data Coalesce_end
tgt Mon Jan 5 08:50:59 GMT staged_data create: Target_failed (snapshot create failed)

 The key was that there were too many snapshots in the destination volume.

Target_failed (snapshot create failed)

Once the number of snapshot was reduced and the next scheduled transfer came around the status returned to normal and transfers returned to normal.

I couldn't get any change using the command line. It did just fix itself oince there were available snapshots.

Richard

[borismekler]

Sort of, I ended up following KB ID 2012307 in order to re-baseline the destination while keeping existing snapshots.