acrolinx

Author: b-ahibbard

articles/azure-netapp-files/faq-nfs.md

@@ -12,7 +12,7 @@ ms.date: 02/21/2023
 
 This article answers frequently asked questions (FAQs) about the NFS protocol of Azure NetApp Files.
 
-## I want to have a volume mounted automatically when an Azure VM is started or rebooted.  How do I configure my host for persistent NFS volumes?
+## I want to have a volume mounted automatically when an Azure VM is started or rebooted. How do I configure my host for persistent NFS volumes?
 
 For an NFS volume to automatically mount at VM start or reboot, add an entry to the `/etc/fstab` file on the host. 
 
@@ -44,17 +44,17 @@ Make sure that `CaseSensitiveLookup` is enabled on the Windows client to speed u
 
 For NFSv4.1 clients, Azure NetApp Files supports the NFSv4.1 file-locking mechanism that maintains the state of all file locks under a lease-based model. 
 
-Per RFC 3530, Azure NetApp Files defines a single lease period for all state held by an NFS client. If the client does not renew its lease within the defined period, all states associated with the client's lease will be released by the server.  
+Per RFC 3530, Azure NetApp Files defines a single lease period for all state held by an NFS client. If the client doesn't renew its lease within the defined period, all states associated with the client's lease will be released by the server.  
 
 For example, if a client mounting a volume becomes unresponsive or crashes beyond the timeouts, the locks will be released. The client can renew its lease explicitly or implicitly by performing operations such as reading a file.   
 
 A grace period defines a period of special processing in which clients can try to reclaim their locking state during a server recovery. The default timeout for the leases is 30 seconds with a grace period of 45 seconds. After that time, the client's lease will be released. 
 
 Azure NetApp Files also supports [breaking file locks](troubleshoot-file-locks.md).
 
-## Why is the `.snapshot` directory not visible in an NFSv4.1 volume, but it is visible in an NFSv3 volume?
+## Why is the `.snapshot` directory not visible in an NFSv4.1 volume, but it's visible in an NFSv3 volume?
 
-By design, the .snapshot directory is never visible to NFSv4.1 clients. By default, the `.snapshot `directory will be visible to NFSv3 clients. To hide the `.snapshot` directory from NFSv3 clients, edit the properties of the volume to [hide the snapshot path](snapshots-edit-hide-path.md).
+By design, the .snapshot directory is never visible to NFSv4.1 clients. By default, the `.snapshot `directory is visible to NFSv3 clients. To hide the `.snapshot` directory from NFSv3 clients, edit the properties of the volume to [hide the snapshot path](snapshots-edit-hide-path.md).
 
 ## Oracle dNFS
 
@@ -64,22 +64,22 @@ Customers using Oracle 19c and higher must ensure they **are patched for Oracle
 
 If a database is exposed to this bug, network interruptions are highly likely to result in fractured block corruption. Network interruptions include events such as storage endpoint relocation, volume relocation, and storage service maintenance events. The corruption may not necessarily be detected immediately.
 
-This is not a bug on ONTAP or the Azure NetApp Files service itself. It is the result of an Oracle dNFS bug. The response to an NFS IO during a certain networking interruption or reconfiguration events is mishandled. The database will erroneously write a block that was being updated as it was written. In some cases, the corrupted block will be silently corrected by a later overwrite of that same block. If not, it will eventually be detected by Oracle database processes. An error should be logged in the Alert logs, and the Oracle instance is likely to terminate. In addition, dbv and RMAN operations can detect the corruption.
+This corruption is neither a bug on ONTAP nor the Azure NetApp Files service itself, but the result of an Oracle dNFS bug. The response to an NFS IO during a certain networking interruption or reconfiguration events is mishandled. The database will erroneously write a block that was being updated as it was written. In some cases, a later overwrite of that same block will silently corrupt the corrupted block. If not, Oracle database processes will eventually detect it. An error should be logged in the Alert logs, and the Oracle instance is likely to terminate. In addition, dbv and RMAN operations can detect the corruption.
 
 Oracle publishes [document 1495104.1](https://support.oracle.com/knowledge/Oracle%20Cloud/1495104_1.html), which is continually updated with recommended dNFS patches. If your database uses dNFS, ensure the DBA team is checking for updates in this document.
 
 ### Are there any patches required for use of Oracle dNFS with NFSv4.1?
 
-If your databases are using Oracle dNFS with NFSv4.1, they **need to be patched for Oracle bugs 33132050 and 33676296**. You may have to request a backport for other versions of Oracle. For example, at the time of writing, these patches are available for 19.11, but not yet 19.3. If you cite these bug numbers in the support case, Oracle's support engineers will know what to do.
+If your databases are using Oracle dNFS with NFSv4.1, they **need to be patched for Oracle bugs 33132050 and 33676296**. You may have to request a backport for other versions of Oracle. For example, at the time of writing, these patches are available for 19.11, but not yet 19.3. If you cite these bug numbers in the support case, Oracle's support engineers know what to do.
 
 This requirement applies to ONTAP-based systems and services in general, which includes both on-premises ONTAP and Azure NetApp Files.
 
-Examples of the potential problems if these patches are not applied:
+Examples of the potential problems if these patches aren't applied:
 
 1. Database hangs on backend storage endpoint moves.
 1. Database hangs on Azure NetApp Files service maintenance events.
 1. Brief Oracle hangs during normal operation that may or may not be noticeable.
-1. Slow Oracle shutdowns: if you monitor the shutdown process, you'll see pauses that could add up to minutes of delays as dNFS I/O times out.
+1. Slow Oracle shutdowns: if you monitor the shutdown process, you see pauses that could add up to minutes of delays as dNFS I/O times out.
 1. Incorrect dNFS reply caching behavior on reads that will hang a database.
 
 The patches include a change in dNFS session management and NFS reply caching that resolves these problems.
@@ -88,7 +88,7 @@ The patches include a change in dNFS session management and NFS reply caching th
 
 ### Can I use multipathing with Oracle dNFS and NFSv4.1?
 
-dNFS will not work with multiple paths when using NFSv4.1. If you need multiple paths, you will have to use NFSv3. dNFS requires cluster-wide `clientID` and `sessionID` trunking for NFSv4.1 to work with multiple paths, and this is not supported by Azure NetApp Files. The result when trying to use this is a hang during dNFS startup
+When using NFSv4.1, dNFS won't work with multiple paths. If you need multiple paths, you have to use NFSv3. dNFS requires cluster-wide `clientID` and `sessionID` trunking for NFSv4.1 to work with multiple paths, which Azure NetApp Files does not support. As a result, you'll experience a hang during dNFS startup
 
 ## Next steps