On Wed, 29 Nov 2000, Moshe Linzer wrote:
We set up the 2 volumes with the same amount of raw space.
What was the disk configuration of the volumes? Available space is calculated in different manners for volumes with different disk geometries.
However, the source volume had a snap reserve of 5%, so we changed to target volume to snap reserve of 5% before taking it offline. We started the snapmirror, and the volume filled up to 103%. I checked, and the snap reserve had been reset to 20%, thus reducing the free space on the target volume, and preventing the mirror from completing.
If the SnapMirror initial transfer succeeded, then it should just work from then on, unless you grow the source volume, or delete a SnapMirror snapshot on the source, or something similar to that.
Did you get some sort of error message that signaled that the mirror was prevented from completing due to a lack of space?
I made the volume writable, and tried to reset the snap reserve to 5%, but the same thing happened. I only succeeded in completing the mirror by adding a disk to the target volume, thus allowing enough space, even with a snap reserve of 20%. This sounds like a bug - why should snap reserve be reset on the target volume? Has anyone heard of this before?
The snap reserve "bug" just makes things look weird; it has no practical effect on whether SnapMirror will work or not. This is documented as public burt #18560:
TITLE: Snapreserve value not propagated to snapmirror destination
DESCRIPTION: Snapreserve value not propagated to snapmirror destination. This will cause df numbers to look quite different between the source and destination.
WORKAROUND: Don't worry about it. It actually has no affect on whether SnapMirror will function. It is more of a cosmetic thing.
FIX: Very small fix that just leaves snap reserve percent untouched.
The fix was made for release 6.0. I do not believe it has been made for any of the 5.X releases.
-- Shane
------- It's always a good idea to bypass NVRAM.