On Tue, Oct 21, 2008 at 6:04 PM, George T Chen gtchen@yahoo-inc.com wrote:
I know you say that you did the snapmirror release, so maybe there's a bug somewhere, but the presence of the snapmirror tag on snapshot "filerA(0101195225)_preforce.7" would indicate that the release never completed. That snapshot would have been created from when filerA was a snapmirror destination. Regardless, I believe you can safely remove the Aug 20 snapshot.
I do not believe the presence of the snapmirror tag means that "snapmirror status" will automatically include it. If you modify the /etc/snapmirror.conf file to include the old filerB-filerA entry, you should see the entry with a lag of months.
This by itself didn't work. I ended up doing the following: - Reviewed 'snapmirror status -l' on each of the filers to ensure that the old snapshot was in fact NOT my baseline snapshot. :-) - In spite of the (snapmirror) tag on the snapshot on the SnapMirror volume, I did a 'snap delete' and this removed the snapshot. - By deleting the snapshot on the source, this caused each of the destinations to throw a snapmirror.dst.snapDelErr as they expected the source to have this snapshot when it didn't. - I did a 'snapmirror quiesce' and 'snapmirror break' on each of the destinations and tried to 'snapmirror update'. This failed. - I did a 'snap delete' on each of the destinations to remove the snapshot. - I did a 'snapmirror resync' on each of the destinations and this made the snapmirror.dst.snapDelErr go away. SnapMirror got into a happier state after that.
I believe we've probably bumped up against a SnapMirror bug in 7.2.3 as this behavior (old snapshots persist long after a SnapMirror release) is not quite what I'd expect.