Why is the Qtree SnapMirror transfer size larger than expected?

 

Solution ID: ntapcs8544
Last updated: 6 DEC 2007

Why is the Qtree SnapMirror transfer size larger than expected?

View Environment section

Symptoms
SnapMirror status output shows transfers that are larger than the sum of changes in the qtree that was replicated.

Qtree SnapMirror (QSM) transfer size is higher then client utilities calculate.

Why am I getting Stale File Handle errors from my mounted exports on a QSM destination?

 
Why is the Qtree SnapMirror transfer size larger than expected?

Cause of this problem
Although the qtree was unchanged, something changed in the volume where the qtree resides.

Solution
The files associated with a qtree are unchanged, but changes were made to an inode that shares an "inodefile" block with the qtree.  Because of this, Data ONTAP transfers the metadata which contains the associated attributes, such as time and permissions, from the qtree inode. None of the unchanged data is transferred. This prevents a security hole where permissions are changed on a file, but are not replicated.

Client utilities such as rsync can determine how many bytes have changed.  However, they cannot determine how many blocks of the file were impacted and will need to be retransmitted. For example:
 
If 100 bytes are inserted into the middle of a 10 MB file, all of the trailing bytes will be shifted down. Utilities like Rsync are able to see the 100 byte change, but they are unable to see the other 5242880 bytes or the inode metadata that has to be transmitted because of the shifting of blocks.

 

Environment
EnvironmentBookmark
 
Data ONTAP
NetApp filer
NearStore appliance
SnapMirror