Additional acrolinx fixes.

wmgries · wmgries · commit da8b348f2497 · 2024-10-07T23:52:09.000-07:00
diff --git a/articles/storage/files/understanding-billing.md b/articles/storage/files/understanding-billing.md
@@ -76,7 +76,7 @@ If you're migrating to Azure Files from on-premises or comparing Azure Files to
 ## Provisioned v2 model
 The provisioned v2 model for Azure Files pairs predictability of total cost of ownership with flexibility, allowing you to create a file share that meets your exact storage and performance requirements. When you create a new provisioned v2 file share, you specify how much storage, IOPS, and throughput your file share needs. The amount of each quantity that you provision determines your total bill. 
 
-The amount of storage, IOPS, and throughput you provision are the guaranteed limits of your file share's usage. For example, if you provision a 2 TiB share, when you have added 2 TiB of data to your share, your share will be full and you will not be able to add more data unless you increase the size of your share, or delete some of the data. Credit-based IOPS bursting provides additional flexibility around usage, on a best-effort basis, while credits remain.
+The amount of storage, IOPS, and throughput you provision are the guaranteed limits of your file share's usage. For example, if you provision a 2 TiB share and upload 2 TiB of data to your share, your share will be full and you will not be able to add more data unless you increase the size of your share, or delete some of the data. Credit-based IOPS bursting provides added flexibility around usage, on a best-effort basis, while credits remain.
 
 The amount of storage, IOPS, and throughput you provision can be dynamically scaled up or down as your needs change, however, you can only decrease a provisioned quantity only after 24 hours have elapsed since your last quantity increase. Storage, IOPS, and throughput changes are effective within a few minutes after a provisioning change.  
 
@@ -130,7 +130,7 @@ By default, we recommended IOPS and throughput provisioning based on the provisi
 Depending on your individual file share requirements, you may find that you require more or less IOPS or throughput than our recommendations, and can optionally override these recommendations with your own values as desired.
 
 ### Provisioned v2 bursting
-Credit-based IOPS bursting provides additional flexibility around IOPS usage. This flexibility is best used as a buffer against unanticipated IO-spikes. For established IO patterns, we recommend provisioning for IO peaks.
+Credit-based IOPS bursting provides added flexibility around IOPS usage. This flexibility is best used as a buffer against unanticipated IO-spikes. For established IO patterns, we recommend provisioning for IO peaks.
 
 Burst IOPS credits accumulate whenever traffic for your file share is below provisioned (baseline) IOPS. Whenever a file share's IOPS usage exceeds the provisioned IOPS and there are available burst IOPS credits, the file share can burst up to the maximum allowed burst IOPS limit. File shares can continue to burst as long as there are credits remaining, but this is based on the number of burst credits accrued. Each IO beyond provisioned IOPS consumes one credit. Once all credits are consumed, the share returns to the provisioned IOPS. IOPS against the file share don't have to do anything special to use bursting. Bursting operates on a best effort basis.  
 
@@ -191,7 +191,7 @@ Consumption against the provisioned v2 billing meters are emitted hourly in term
 ## Provisioned v1 model
 The provisioned v1 method provides storage, IOPS and throughput in a fixed ratio to each other, similar to how storage is purchased in an on-premises storage solution. When you create a new provisioned v1 file share, you specify how much storage your share needs, and IOPS and throughput are computed values. The provisioned v1 model for Azure Files is only available for SSD file shares. 
 
-The amount of storage you provision determines the guaranteed storage, IOPS, and throughput limits of your file share's usage. For example, if you provision a 2 TiB share, when you have added 2 TiB of data to your share, your share will be full and you will not be able to add more data unless you increase the size of your share, or delete some of the data. Credit-based IOPS bursting provides additional flexibility around usage, on a best-effort basis, while credits remain.
+The amount of storage you provision determines the guaranteed storage, IOPS, and throughput limits of your file share's usage. For example, if you provision a 2 TiB share and upload 2 TiB of data to your share, your share will be full and you will not be able to add more data unless you increase the size of your share, or delete some of the data. Credit-based IOPS bursting provides added flexibility around usage, on a best-effort basis, while credits remain.
 
 Unlike purchasing storage on-premises, provisioned v1 file shares can be dynamically scaled up or down as your needs change, however, you can only decrease the provisioned storage only after 24 hours have elapsed since your last storage increase. Storage, IOPS, and throughput changes are effective within a few minutes after a provisioning change.
 
@@ -208,7 +208,7 @@ The provisioned v1 model is provided for SSD file shares in storage accounts wit
 SSD file shares using the provisioned v1 model are generally available in most Azure regions. See [Azure products by region](https://azure.microsoft.com/explore/global-infrastructure/products-by-region) for more information.
 
 ### Provisioning detail
-When you create a provisioned v1 file share, you specify how much storage your share needs. Each GiB that you provision entitles you to additional IOPS and throughput in a fixed ratio. File shares are limited based on the following attributes: 
+When you create a provisioned v1 file share, you specify how much storage your share needs. Each GiB that you provision entitles you to more IOPS and throughput in a fixed ratio. File shares are limited based on the following attributes: 
 
 | Item | Value |
 |-|-|
@@ -224,10 +224,10 @@ The amount of IOPS and throughput provisioned on the share are determined by the
 | Computed provisioned (baseline) IOPS | `MIN(3000 + 1 * ProvisionedStorageGiB, 102400)` |
 | Computed provisioned throughput (MiB / sec) | `100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB)` |
 
-Depending on your individual file share requirement, you may find that you require more IOPS or throughput than our provisioning formulas provide. In this case, you will need to provision additional storage to get the required IOPS or throughput.
+Depending on your individual file share requirement, you may find that you require more IOPS or throughput than our provisioning formulas provide. In this case, you will need to provision more storage to get the required IOPS or throughput.
 
 ### Provisioned v1 bursting
-Credit-based IOPS bursting provides additional flexibility around IOPS usage. This flexibility is best used as a buffer against unanticipated IO-spikes. For established IO patterns, we recommend provisioning for IO peaks.
+Credit-based IOPS bursting provides added flexibility around IOPS usage. This flexibility is best used as a buffer against unanticipated IO-spikes. For established IO patterns, we recommend provisioning for IO peaks.
 
 Burst IOPS credits accumulate whenever traffic for your file share is below provisioned (baseline) IOPS. Whenever a file share's IOPS usage exceeds the provisioned IOPS and there are available burst IOPS credits, the file share can burst up to the maximum allowed burst IOPS limit. File shares can continue to burst as long as there are credits remaining, but this is based on the number of burst credits accrued. Each IO beyond provisioned IOPS consumes one credit. Once all credits are consumed, the share returns to the provisioned IOPS. IOPS against the file share don't have to do anything special to use bursting. Bursting operates on a best effort basis.  
 
@@ -410,7 +410,7 @@ Azure Files tracks three distinct quantities with respect to share capacity:
 
 - **Provisioned size or quota**: With both provisioned and pay-as-you-go file shares, you specify the maximum size that the file share is allowed to grow to. In provisioned file shares, this value is called the provisioned size. Whatever amount you provision is what you pay for, regardless of how much you actually use. In pay-as-you-go file shares, this value is called quota and doesn't directly affect your bill. Provisioned size is a required field for provisioned file shares. For pay-as-you-go file shares, if provisioned size isn't directly specified, the share will default to the maximum value supported by the storage account (100 TiB).
 
-- **Logical size**: The logical size of a file share or file relates to how big it is without considering how it's actually stored, where additional optimizations might be applied. The logical size of the file is how many KiB/MiB/GiB would be transferred over the wire if you copied it to a different location. In both provisioned and pay-as-you-go file shares, the total logical size of the file share is used for enforcement against provisioned size/quota. In pay-as-you-go file shares, the logical size is the quantity used for the data at-rest usage billing. Logical size is referred to as "size" in the Windows properties dialog for a file/folder and as "content length" by Azure Files metrics.
+- **Logical size**: The logical size of a file share or file relates to how big it is without considering how it's actually stored, where storage optimizations might be applied. The logical size of the file is how many KiB/MiB/GiB would be transferred over the wire if you copied it to a different location. In both provisioned and pay-as-you-go file shares, the total logical size of the file share is used for enforcement against provisioned size/quota. In pay-as-you-go file shares, the logical size is the quantity used for the data at-rest usage billing. Logical size is referred to as "size" in the Windows properties dialog for a file/folder and as "content length" by Azure Files metrics.
 
 - **Physical size**: The physical size of the file relates to the size of the file as encoded on disk. This might align with the file's logical size, or it might be smaller, depending on how the file has been written to by the operating system. A common reason for the logical size and physical size to be different is by using [sparse files](/windows/win32/fileio/sparse-files). The physical size of the files in the share is used for snapshot billing, although allocated ranges are shared between snapshots if they are unchanged (differential storage).
 
@@ -423,7 +423,7 @@ Costs break down into three buckets:
 
 - **Transaction costs for the value-added service.** Some value-added services have their own concept of transactions on top of the Azure Files billing model selected. These transactions will show up on your bill under the value-added service's charges; however, they relate directly to how you use the value-added service with your file share.
 
-- **Azure Files costs for using a value-added service.** Azure Files doesn't directly charge customers for adding value-added services, but as part of adding value to the Azure file share, the value-added service might increase the costs that you see on your Azure file share. This is easy to see with pay-as-you-go file shares, because of transaction charges. If the value-added service does transactions against the file share on your behalf, they will show up in your Azure Files transaction bill even though you didn't directly do those transactions yourself. This applies to provisioned file shares as well, although it might be less noticeable. Additional transactions against premium file shares from value-added services count against your provisioned IOPS numbers, meaning that value-added services might require provisioning more storage to have enough IOPS or throughput available for your workload.
+- **Azure Files costs for using a value-added service.** Azure Files doesn't directly charge customers for adding value-added services, but as part of adding value to the Azure file share, the value-added service might increase the costs that you see on your Azure file share. This is easy to see with pay-as-you-go file shares, because of transaction charges. If the value-added service does transactions against the file share on your behalf, they will show up in your Azure Files transaction bill even though you didn't directly do those transactions yourself. This applies to provisioned file shares as well, although it might be less noticeable. Transactions against provisioned file shares from value-added services count against your provisioned IOPS numbers, meaning that value-added services might require provisioning more storage to have enough IOPS or throughput available for your workload.
 
 When computing the total cost of ownership for your file share, you should consider the costs of Azure Files and of all value-added services that you would like to use with Azure Files.
 
@@ -444,7 +444,7 @@ When considering the costs of using Azure Backup, consider the following:
 - **Protected instance licensing cost for Azure file share data.** Azure Backup charges a protected instance licensing cost per storage account containing backed up Azure file shares. A protected instance is defined as 250 GiB of Azure file share storage. Storage accounts containing less than 250 GiB are subject to a fractional protected instance cost. For more information, see [Azure Backup pricing](https://azure.microsoft.com/pricing/details/backup/). You must select *Azure Files* from the list of services Azure Backup can protect.
 
 - **Azure Files costs.** Azure Backup increases the costs of Azure Files in the following ways:
-    - **Differential costs from Azure file share snapshots.** Azure Backup automates taking Azure file share snapshots on an administrator-defined schedule. Snapshots are always differential; however, the additional cost added to the total bill depends on the length of time snapshots are kept and the amount of churn on the file share during that time. This dictates how different the snapshot is from the live file share and therefore how much additional data is stored by Azure Files.
+    - **Differential costs from Azure file share snapshots.** Azure Backup automates taking Azure file share snapshots on an administrator-defined schedule. Snapshots are always differential; however, the added cost added depends on the length of time snapshots are kept and the amount of churn on the file share during that time. This dictates how different the snapshot is from the live file share and therefore how much extra data is stored by Azure Files.
 
     - **Transaction costs from restore operations.** Restore operations from the snapshot to the live share will cause transactions. For standard file shares, this means that reads from snapshots/writes from restores will be billed as normal file share transactions. For provisioned file shares, these operations are counted against the provisioned IOPS for the file share.
 
@@ -453,7 +453,7 @@ Microsoft Defender supports Azure Files as part of its Microsoft Defender for St
 
 Microsoft Defender for Storage doesn't support antivirus capabilities for Azure file shares.
 
-The main cost from Microsoft Defender for Storage is an additional set of transaction costs that the product levies on top of the transactions that are done against the Azure file share. Although these costs are based on the transactions incurred in Azure Files, they aren't part of the billing for Azure Files, but rather are part of the Microsoft Defender pricing. Microsoft Defender for Storage charges a transaction rate even on provisioned file shares, where Azure Files includes transactions as part of IOPS provisioning. The current transaction rate can be found on [Microsoft Defender for Cloud pricing page](https://azure.microsoft.com/pricing/details/defender-for-cloud/) under the *Microsoft Defender for Storage* table row.
+The main cost from Microsoft Defender for Storage is an extra set of transaction costs that the product levies on top of the transactions that are done against the Azure file share. Although these costs are based on the transactions incurred in Azure Files, they aren't part of the billing for Azure Files, but rather are part of the Microsoft Defender pricing. Microsoft Defender for Storage charges a transaction rate even on provisioned file shares, where Azure Files includes transactions as part of IOPS provisioning. The current transaction rate can be found on [Microsoft Defender for Cloud pricing page](https://azure.microsoft.com/pricing/details/defender-for-cloud/) under the *Microsoft Defender for Storage* table row.
 
 Transaction heavy file shares will incur significant costs using Microsoft Defender for Storage. Based on these costs, you might want to opt-out of Microsoft Defender for Storage for specific storage accounts. For more information, see [Exclude a storage account from Microsoft Defender for Storage protections](/azure/defender-for-cloud/defender-for-storage-exclude).
 
