ONTAP Discussions

Highlighted

Ontap 9 Filehandle preservation

I read that SVM-DR relations can preserve volume MSIDs which allows NFS file handles to remain valid in a disaster recovery scenario without the need to re-mount.  I tested this with a AFFA300 running 9.1P1 and RHEL VM using NFSv3.  Confirmed the msid-preserve is set to true.  Performed a SVM DR failover from one site to another site the unix mount froze and was not able to recover unless a lazy unmount was performed.  Is there mount options that need to be added or is this only for NFSv4? 

5 REPLIES 5
Highlighted

Re: Ontap 9 Filehandle preservation

To be sure - DR SVM was using the same IP addresses? Were they reacheable from NFS client? This may be network issue like stale ARP caches.
Highlighted

Re: Ontap 9 Filehandle preservation

If you've moved the SVM/Cluster from 8.3 to 9, the SVM DR relationship by default will not preserve MSIDs. New relationships created under 9.0 will however.

 

We have instructions for upgrading the DR relationship in the first case, as well as general troubleshooting at https://kb.netapp.com/support/s/article/ka31A0000000jXPQAY/how-to-preserve-nfs-file-handles-and-volume-msids-with-svm-dr-vserver-disaster-recovery?lan...

 

Please let me know if this helps!

Highlighted

Re: Ontap 9 Filehandle preservation

Hi, i did read that KB article and this is all done from 9.1P1.  No migration.  Did verify that MSIDs are the same on both locations. 

Highlighted

Re: Ontap 9 Filehandle preservation

No, DR SVM is using different IP.  The VLAN is not stretched.  After DR cutover all IPs are reachable and DNS of SVM was manually changed to point to DR LIF.  Mount still hung doing a ls command. 

Highlighted

Re: Ontap 9 Filehandle preservation

Client NFS mount is tied to specific address. There is no way to transparently migrate to different IP - client must remount. It is not related to MSID..

View solution in original post

Check out the KB!
Knowledge Base
All Community Forums