Merge pull request #285082 from b-ahibbard/cifs

spell out acronyms for NIC & CIFS

Author: prmerger-automator[bot]

articles/azure-netapp-files/access-smb-volume-from-windows-client.md

@@ -5,7 +5,7 @@ ms.service: azure-netapp-files
 ms.topic: how-to
 author: b-ahibbard
 ms.author: anfdocs
-ms.date: 09/21/2023
+ms.date: 08/20/2024
 ---
 # Access SMB volumes from Microsoft Entra joined Windows virtual machines
 
@@ -34,7 +34,7 @@ You can use Microsoft Entra ID with the Hybrid Authentication Management module
 ## Steps
 
 The configuration process takes you through five process:
-* Add the CIFS SPN to the computer account
+* Add the CIFS (Common Internet File System) SPN to the computer account
 * Register a new Microsoft Entra application
 * Sync CIFS password from AD DS to the Microsoft Entra application registration 
 * Configure the Microsoft Entra joined VM to use Kerberos authentication

articles/azure-netapp-files/azure-netapp-files-network-topologies.md

@@ -94,7 +94,7 @@ If the VNet is peered with another VNet, you can't expand the VNet address space
 >[!IMPORTANT]
 > Ensure the address space size of the Azure NetApp Files VNet is larger than its delegated subnet.
 >
-> For example, if the delegated subnet is /24, the VNet address space containing the subnet must be /23 or larger. Noncompliance with this guideline can lead to unexpected issues in some traffic patterns: traffic traversing a hub-and-spoke topology that reaches Azure NetApp Files via a Network Virtual Appliance does not function properly. Additionally, this configuration can result in failures when creating SMB and CIFS volumes if they attempt to reach DNS through hub-and-spoke network topology. 
+> For example, if the delegated subnet is /24, the VNet address space containing the subnet must be /23 or larger. Noncompliance with this guideline can lead to unexpected issues in some traffic patterns: traffic traversing a hub-and-spoke topology that reaches Azure NetApp Files via a Network Virtual Appliance does not function properly. Additionally, this configuration can result in failures when creating SMB and CIFS (Common Internet File System) volumes if they attempt to reach DNS through hub-and-spoke network topology. 
 >
 > It's also recommended that the size of the delegated subnet be at least /25 for SAP workloads and /26 for other workload scenarios.
 

articles/azure-netapp-files/azure-netapp-files-smb-performance.md

@@ -5,7 +5,7 @@ services: azure-netapp-files
 author: b-hchen
 ms.service: azure-netapp-files
 ms.topic: conceptual
-ms.date: 08/13/2024
+ms.date: 08/20/2024
 ms.author: anfdocs
 ---
 # SMB performance best practices for Azure NetApp Files

articles/azure-netapp-files/azure-netapp-files-troubleshoot-resource-provider-errors.md

@@ -261,7 +261,7 @@ Wait a few minutes and check if the problem persists.
 
 ***Not allowed to mix protocol types CIFS and NFS***
 
-This error occurs when you're trying to create a volume that has both the CIFS (SMB) and NFS protocol types in the volume properties.
+This error occurs when you're trying to create a volume that has both the CIFS ([Common Internet File System] SMB) and NFS protocol types in the volume properties.
 
 * Cause:   
 Both the CIFS (SMB) and NFS protocol types are used in the volume properties.
@@ -674,7 +674,7 @@ You try to create a volume from a snapshot and volume ends in an error state.
 * Solution:   
 Delete the volume, then retry the volume creation operation from the snapshot.
 
-***Deletion of resource group fails during the NIC clearing process*** 
+***Deletion of resource group fails during the network interface card (NIC) clearing process*** 
 
 * Cause:   
  The resource group you try to delete might have volumes associated with it.

articles/azure-netapp-files/configure-network-features.md

@@ -5,7 +5,7 @@ services: azure-netapp-files
 author: b-hchen
 ms.service: azure-netapp-files
 ms.topic: how-to
-ms.date: 07/10/2024
+ms.date: 08/20/2024
 ms.custom: references_regions
 ms.author: anfdocs
 ---
@@ -71,7 +71,7 @@ This section shows you how to set the network features option when you create a
 
 ## Edit network features option for existing volumes
 
-You can edit the network features option of existing volumes from *Basic* to *Standard* network features. The change you make applies to all volumes in the same *network sibling set* (or *siblings*). Siblings are determined by their network IP address relationship. They share the same NIC for mounting the volume to the client or connecting to the remote share of the volume. At the creation of a volume, its siblings are determined by a placement algorithm that aims for reusing the IP address where possible.
+You can edit the network features option of existing volumes from *Basic* to *Standard* network features. The change you make applies to all volumes in the same *network sibling set* (or *siblings*). Siblings are determined by their network IP address relationship. They share the same network interface card (NIC) for mounting the volume to the client or connecting to the remote share of the volume. At the creation of a volume, its siblings are determined by a placement algorithm that aims for reusing the IP address where possible.
 
 >[!IMPORTANT]
 >It's not recommended that you use the edit network features option with Terraform-managed volumes due to risks. You must follow separate instructions if you use Terraform-managed volumes. For more information see, [Update Terraform-managed Azure NetApp Files volume from Basic to Standard](#update-terraform-managed-azure-netapp-files-volume-from-basic-to-standard).

articles/azure-netapp-files/cool-access-introduction.md

@@ -27,7 +27,7 @@ In the initial write, data blocks are assigned a "warm" temperature value (in th
 By `Default` (unless cool access retrieval policy is configured otherwise), data blocks on the cool tier that are read randomly again become "warm" and are moved back to the hot tier. Once marked as _warm_, the data blocks are again subjected to the temperature scan. However, large sequential reads (such as index and antivirus scans) on inactive data in the cool tier don't "warm" the data nor do they trigger inactive data to be moved back to the hot tier.
 
 >[!IMPORTANT]
->If you're using a third-party backup service, configure it to use NDMP instead of the CIFS or NFS protocols. NDMP reads do not affect the temperature of the data.
+>If you're using a third-party backup service, configure it to use NDMP instead of the CIFS (Common Internet File System) or NFS protocols. NDMP reads do not affect the temperature of the data.
 
 Metadata is never cooled and always remains in the hot tier. As such, the activities of metadata-intensive workloads (for example, high file-count environments like chip design, VCS, and home directories) aren't affected by tiering.
 

articles/azure-netapp-files/faq-application-resilience.md

@@ -55,7 +55,7 @@ Because most problems with this HA solution stem from inaccurate OS-level file l
 
 ## I'm running Apache ActiveMQ with LevelDB or KahaDB on Azure NetApp Files. What precautions can I take to avoid disruptions due to storage service maintenance events despites using the *SMB* protocol?
 
-The general industry recommendation is to [not run your KahaDB shared storage on CIFS/SMB](https://www.openlogic.com/blog/activemq-community-deprecates-leveldb-what-you-need-know). If you're having trouble maintaining accurate lock state, check out the JDBC Pluggable Storage Locker, which can provide a more reliable locking mechanism. For support or consultancy on ActiveMQ HA architectures and deployments, you should [contact OpenLogic by Perforce](https://www.openlogic.com/contact-us).
+The general industry recommendation is to [not run your KahaDB shared storage on CIFS [Common Internet File System]/SMB](https://www.openlogic.com/blog/activemq-community-deprecates-leveldb-what-you-need-know). If you're having trouble maintaining accurate lock state, check out the JDBC Pluggable Storage Locker, which can provide a more reliable locking mechanism. For support or consultancy on ActiveMQ HA architectures and deployments, you should [contact OpenLogic by Perforce](https://www.openlogic.com/contact-us).
 
 ## I’m running Boomi on Azure NetApp Files. What precautions can I take to avoid disruptions due to storage service maintenance events?
 

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

@@ -5,7 +5,7 @@ ms.service: azure-netapp-files
 ms.topic: conceptual
 author: b-hchen
 ms.author: anfdocs
-ms.date: 08/13/2024
+ms.date: 08/20/2024
 ---
 # Performance FAQs for Azure NetApp Files
 
@@ -19,7 +19,7 @@ You can take the following actions per the performance requirements:
 - Select the desired service level and size for the capacity pool.
 - Create a volume with the desired quota size for the capacity and performance.
 
-There is no need to set accelerated networking for the NICs in the dedicated subnet of Azure NetApp Files. [Accelerated networking](../virtual-network/virtual-machine-network-throughput.md) is a capability that only applies to Azure virtual machines. Azure NetApp Files NICs are optimized by design.
+There is no need to set accelerated networking for the network interface cards (NICs) in the dedicated subnet of Azure NetApp Files. [Accelerated networking](../virtual-network/virtual-machine-network-throughput.md) is a capability that only applies to Azure virtual machines. Azure NetApp Files NICs are optimized by design.
 
 ## How do I monitor Azure NetApp Files volume performance 
 

articles/azure-netapp-files/performance-oracle-multiple-volumes.md

@@ -5,7 +5,7 @@ services: azure-netapp-files
 author: b-ahibbard
 ms.service: azure-netapp-files
 ms.topic: conceptual
-ms.date: 04/24/2024
+ms.date: 08/20/2024
 ms.author: anfdocs
 ---
 
@@ -100,7 +100,7 @@ Read the [Azure Compute documentation](/azure/architecture/guide/technology-choi
 
 #### Available network bandwidth 
 
-It's important to understand the difference between the available bandwidth of the VM network interface and the metered bandwidth applied against the same. When [Azure Compute documentation](../virtual-network/virtual-machine-network-throughput.md) speaks to network bandwidth limits, these limits are applied on egress (write) only. Ingress (read) traffic is not metered and as such is limited only by the physical bandwidth of the NIC itself. The network bandwidth of most VMs outpaces the egress limit applied against the machine.
+It's important to understand the difference between the available bandwidth of the VM network interface and the metered bandwidth applied against the same. When [Azure Compute documentation](../virtual-network/virtual-machine-network-throughput.md) speaks to network bandwidth limits, these limits are applied on egress (write) only. Ingress (read) traffic is not metered and as such is limited only by the physical bandwidth of the network interface card (NIC) itself. The network bandwidth of most VMs outpaces the egress limit applied against the machine.
 
 As Azure NetApp Files volumes are network attached, the egress limit can be understood as being applied against writes specifically whereas ingress is defined as reads and read-like workloads. While the egress limit of most machines is greater than the network bandwidth of the NIC, the same cannot be said for the E104_v5 used in testing for this article. The E104_v5 has a 100 Gbps NIC with the egress limit set at 100 Gbps as well. By comparison, the E96_v5, with its 100 Gbps NIC has an egress limit of 35 Gbps with ingress unfettered at 100 Gbps. As VMs decrease in size, egress limits decrease but ingress remains unfettered by logically imposed limits. 
 

articles/azure-netapp-files/understand-file-locks.md

@@ -5,7 +5,7 @@ services: azure-netapp-files
 author: netapp-manishc
 ms.service: azure-netapp-files
 ms.topic: conceptual
-ms.date: 06/12/2023
+ms.date: 08/20/2024
 ms.author: anfdocs
 ---
 # Understand file locking and lock types in Azure NetApp Files
@@ -20,7 +20,7 @@ There are several types of NFS locks, which include:
 Shared locks can be used by multiple processes at the same time and can only be issued if there are no exclusive locks on a file. These locks are intended for read-only work but can be used for writes (such as with a database).
 
 **Exclusive locks:**
-Exclusive locks operate the same as exclusive locks in CIFS/SMB: only one process can use the file when there is an exclusive lock. If any other processes have locked the file, an exclusive lock can't be issued unless that process was [forked](http://linux.die.net/man/2/fork).
+Exclusive locks operate the same as exclusive locks in SMB: only one process can use the file when there is an exclusive lock. If any other processes have locked the file, an exclusive lock can't be issued unless that process was [forked](http://linux.die.net/man/2/fork).
 
 **Delegations:**
 Delegations are used only with NFSv4.x and are assigned when the NFS server options are enabled and the client supports NFSv4.x delegations. Delegations provide a way to cache operations on the client side by creating a “soft” lock to the file being used by a client. This improves the performance of specific workloads by reducing the number of calls between the client and server and are similar to SMB opportunistic locks. Azure NetApp Files currently doesn't support NFSv4.x delegations.