Merge pull request #270123 from b-ahibbard/cool-access

new cool access regions: west europe; s. central us

Author: prmerger-automator[bot]

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

@@ -53,6 +53,7 @@ Standard storage with cool access is supported for the following regions:
 * Norway East
 * Norway West
 * Qatar Central
+* South Central US
 * Southeast Asia
 * Switzerland North 
 * Switzerland West 
@@ -64,6 +65,7 @@ Standard storage with cool access is supported for the following regions:
 * US Gov Arizona
 * US Gov Texas
 * US Gov Virginia 
+* West Europe
 * West US
 * West US 2
 * West US 3

articles/azure-netapp-files/manage-manual-qos-capacity-pool.md

@@ -30,9 +30,6 @@ You can change a capacity pool that currently uses the auto QoS type to use the
 > Setting the capacity type to manual QoS is a permanent change. You cannot convert a manual QoS type capacity tool to an auto QoS capacity pool.  
 > At conversion time, throughput levels might be capped to conform to the throughput limits for volumes of the manual QoS type. See [Resource limits for Azure NetApp Files](azure-netapp-files-resource-limits.md#resource-limits).
 
->[!NOtE]
->An auto QoS capacity pool enabled for [standard storage with cool access](cool-access-introduction.md) cannot be converted to a capacity pool using manual QoS. 
-
 1. From the management blade for your NetApp account, select **Capacity pools** to display existing capacity pools.   
 
 2.	Select the capacity pool that you want to change to using manual QoS.

articles/azure-netapp-files/performance-large-volumes-linux.md

@@ -50,7 +50,7 @@ Tests observed performance thresholds of a single large volume on scale-out and
 | Azure VM egress bandwidth limit | 2000MiB/s (2GiB/s) |
 | Operating system | RHEL 8.4 |
 | Large volume size | 101 TiB Ultra (10,240 MiB/s throughput) |
-| Mount options | hard,rsize=65536,wsize=65536,vers=3  <br /> **NOTE:** Use of both 262144 and 65536 had similar performance results. |
+| Mount options | `hard,rsize=65536,wsize=65536,vers=3`  <br /> **NOTE:** Use of both 262144 and 65536 had similar performance results. |
 
 ### 256-KiB sequential workloads (MiB/s) 
 
@@ -77,7 +77,7 @@ The tests in this section were run with the following configuration:
 | Azure VM egress bandwidth limit | 12,500MiB/s (12.2GiB/s)  |
 | Operating system | RHEL 8.4 |
 | Large volume size | 101 TiB Ultra (10,240 MiB/s throughput) |
-| Mount options | hard,rsize=65536,wsize=65536,vers=3  <br /> **NOTE:** Use of both 262144 and 65536 had similar performance results |
+| Mount options | `hard,rsize=65536,wsize=65536,vers=3` <br /> **NOTE:** Use of both 262144 and 65536 had similar performance results |
 
 The graphs in this section show the results for the client-side mount option of `nconnect` with NFSv3. For more information, see [Linux NFS mount options best practices for Azure NetApp File](performance-linux-mount-options.md#nconnect).