Accidently deleted NetApp volume

Oops!

If you have accidentally deleted a NetApp volume then you can use the volume recovery-queue feature to recover the volume.This feature is available in 8.3 and above. The default retention is 12 hours.

Use the following commands:

1) volume recovery-queue show -vserver svm1
2) volume recovery-queue recover -vserver svm1 -volume <deleted_vol_name> 

NetApp slow performance after volume move operation || deswizzler or deswizzling

After a volume move operation, a WAFL scan needs to be completed. The scan identifies and builds a map of relationship between logical and physical blocks (deswizzler or deswizzling).  Until the scan completes, all read operations use a slower method to read data. 

You can use the following commands to verify if a deswizzle process in in progress.

filer> priv set advanced
filer*> wafl scan status
 
What is deswizzle ? 
You can use the following commands Data within a FlexVol has both a logical location within the volume and a physical location within the containing aggregate. When reading data from a FlexVol, the phyical location of that data must be known to perform the read. 

Under normal circumstances, reads use a fast-path to translate a logical address into a physical address. When SnapMirror transfers a FlexVol to a different aggregate, however, the relationship between logical and physical addressed is changed. The destination aggregate lays out the volume into different physical blocks. Immediately after the SnapMirror transfer, reads to the destination volume will use a different process to translate logical address into physical addresses. This slow-path is less efficient and may require an additional disk read to access a block of data. As soon as a flexvol snapmirror update finishes, the destination storage controller will launch a scanner to recreate the fast-path metadata. Once the scan finishes, reads to the SnapMirror destination will use the normal fast-path. This process is called deswizzling. 


 

NetApp autosupport troubleshooting

Here is a great link to all things wonderful about NetApp Autosupport
https://mysupport.netapp.com/NOW/knowledge/docs/olio/autosupport/

This blog covers some tips on how to troubleshoot issues around Autosupport failures. The troubleshooting steps are useful for users who have intermediate level of NetApp skills (like me).

If you have not received an auto support message then you can use the following steps to troubleshoot:
1) The following command lists the autosupport messages sent in the last 24 hours:
        system autosupport history show -last-update >24h
 
2) The second column in the above command output is the sequence number. Note the sequence number and we will use the sequence number in the next step.

3) The following command lists details about the autosupport failure. Notice the following fields   (Destination for this Autosupport, Status of delivery, Delivery attempts and Last Error)
       system autosupport history show -sequence-num 262 -instance



4)  The above command shows that the error was because the STMP messages was not transmitted because the system could not resolve the host name.

5) The next step would be to verify if the autosupport settings, send a test autosupport and look for more information in the logs

1.  To verify the configuration settings on the node:  system autosupport show -node <node name> -instance
2. To send a test autosupport  system node autosupport invoke -node * -type test -uri mailto:me@here.com -message "Did you see this"
3. The notifyd.log has more information and here are the steps to enable it:    mynode::> set diag
 mynode::*> debug log
 mynode::debug log*> files mod notifyd
 mynode::debug log*> show -node local -timestamp >12h 

Reference link: 
https://kb.netapp.com/support/s/article/troubleshooting-workflow-autosupport-messages-are-not-received-by-netapp-http-smtp-or-partner-smtp?language=en_US