Addressed review feedback

Author: ManikaDhiman

WindowsServerDocs/storage/storage-spaces/cache.md

@@ -1,10 +1,10 @@
 ---
 title: Understanding the storage pool cache in Azure Stack HCI and Windows Server clusters
-description: How read and write caching works to accelerate performance in Storage Spaces Direct.
+description: How to read and write caching works to accelerate performance in Storage Spaces Direct.
 author: robinharwood
 ms.author: roharwoo
 ms.topic: conceptual
-ms.date: 02/10/2025
+ms.date: 02/11/2025
 ---
 
 # Understanding the storage pool cache

WindowsServerDocs/storage/storage-spaces/drive-symmetry-considerations.md

@@ -60,13 +60,13 @@ To see why this happens, consider the following simplified illustration. Each co
 
 As drawn, Server 1 (10 TB) and Server 2 (10 TB) are full. Server 3 has larger drives, therefore its total capacity is larger (15 TB). However, to store more three-way mirror data on Server 3 would require copies on Server 1 and Server 2 too, which are already full. The remaining 5 TB capacity on Server 3 can't be used – it's *stranded* capacity.
 
-:::image type="content" source="media/drive-symmetry-considerations/size-asymmetry-3n-stranded.png" alt-text="Three-way mirror, three servers, stranded capacity." lightbox="media/drive-symmetry-considerations/size-asymmetry-3n-stranded.png":::
+:::image type="content" source="media/drive-symmetry-considerations/size-asymmetry-3n-stranded.png" alt-text="Three-way mirror, three servers, stranded capacity.":::
 
 ### Optimal placement
 
 Conversely, with four servers of 10 TB, 10 TB, 10 TB, and 15 TB capacity and three-way mirror resiliency, it's possible to validly place copies in a way that uses all available capacity, as drawn. Whenever this is possible, the Storage Spaces Direct allocator finds and uses the optimal placement, leaving no stranded capacity.
 
-:::image type="content" source="media/drive-symmetry-considerations/size-asymmetry-4n-no-stranded.png" alt-text="Three-way mirror, four servers, no stranded capacity." lightbox="media/drive-symmetry-considerations/size-asymmetry-4n-no-stranded.png":::
+:::image type="content" source="media/drive-symmetry-considerations/size-asymmetry-4n-no-stranded.png" alt-text="Three-way mirror, four servers, no stranded capacity.":::
 
 The number of servers, the resiliency, the severity of the capacity imbalance, and other factors affect whether there's stranded capacity. **The most prudent general rule is to assume that only capacity available in every server is guaranteed to be usable.**
 
@@ -76,7 +76,7 @@ Storage Spaces Direct can also withstand a cache imbalance across drives and acr
 
 Using cache drives of different sizes may not improve cache performance uniformly or predictably: only IO to [drive bindings](cache.md#server-side-architecture) with larger cache drives may see improved performance. Storage Spaces Direct distributes IO evenly across bindings and doesn't discriminate based on cache-to-capacity ratio.
 
-:::image type="content" source="media/drive-symmetry-considerations/cache-asymmetry.png" alt-text="Cache imbalance." lightbox="media/drive-symmetry-considerations/cache-asymmetry.png":::
+:::image type="content" source="media/drive-symmetry-considerations/cache-asymmetry.png" alt-text="Cache imbalance.":::
 
    > [!TIP]
    > See [Understanding the storage pool cache](cache.md) to learn more about cache bindings.

WindowsServerDocs/storage/storage-spaces/manage-volumes.md

@@ -5,7 +5,7 @@ ms.topic: how-to
 author: robinharwood
 ms.author: roharwoo
 ms.reviewer: jgerend
-ms.date: 07/10/2024
+ms.date: 02/11/2025
 ---
 
 # Manage volumes in Azure Stack HCI and Windows Server
@@ -57,7 +57,7 @@ Before you expand a volume, make sure you have enough capacity in the storage po
 
 In Storage Spaces Direct, every volume is composed of several stacked objects: the cluster shared volume (CSV), which is a volume; the partition; the disk, which is a virtual disk; and one or more storage tiers (if applicable). To resize a volume, you need to resize several of these objects.
 
-:::image type="content" source="media/manage-volumes/volumes-in-smapi.png" alt-text="Diagram shows the layers of a volume, including cluster shard volume, volume, partition, disk, virtual disk, and storage tiers." lightbox="media/manage-volumes/volumes-in-smapi.png":::
+:::image type="content" source="media/manage-volumes/volumes-in-smapi.png" alt-text="Diagram shows the layers of a volume, including cluster shard volume, volume, partition, disk, virtual disk, and storage tiers.":::
 
 To familiarize yourself with them, try running the `Get-` cmdlet with the corresponding noun in PowerShell.
 

WindowsServerDocs/storage/storage-spaces/plan-volumes.md

@@ -4,7 +4,7 @@ description: How to plan storage volumes on Azure Stack HCI and Windows Server c
 author: robinharwood
 ms.author: roharwoo
 ms.topic: conceptual
-ms.date: 02/22/2024
+ms.date: 02/11/2025
 ---
 
 # Plan volumes on Azure Stack HCI and Windows Server clusters
@@ -23,7 +23,7 @@ Volumes are where you put the files your workloads need, such as VHD or VHDX fil
    >[!NOTE]
    > We use term "volume" to refer jointly to the volume and the virtual disk under it, including functionality provided by other built-in Windows features such as Cluster Shared Volumes (CSV) and ReFS. Understanding these implementation-level distinctions is not necessary to plan and deploy Storage Spaces Direct successfully.
 
-:::image type="content" source="media/plan-volumes/what-are-volumes.png" alt-text="Diagram shows three folders labeled as volumes each associated with a virtual disk labeled as volumes, all associated with a common storage pool of disks." lightbox="media/plan-volumes/what-are-volumes.png":::
+:::image type="content" source="media/plan-volumes/what-are-volumes.png" alt-text="Diagram shows three folders labeled as volumes each associated with a virtual disk labeled as volumes, all associated with a common storage pool of disks.":::
 
 All volumes are accessible by all servers in the cluster at the same time. Once created, they show up at **C:\ClusterStorage\\** on all servers.
 
@@ -57,7 +57,7 @@ With two servers in the cluster, you can use two-way mirroring or you can use ne
 
 Two-way mirroring keeps two copies of all data, one copy on the drives in each server. Its storage efficiency is 50 percent; to write 1 TB of data, you need at least 2 TB of physical storage capacity in the storage pool. Two-way mirroring can safely tolerate one hardware failure at a time (one server or drive).
 
-:::image type="content" source="media/plan-volumes/two-way-mirror.png" alt-text="Diagram shows volumes labeled data and copy connected by circular arrows and both volumes are associated with a bank of disks in servers." lightbox="media/plan-volumes/two-way-mirror.png":::
+:::image type="content" source="media/plan-volumes/two-way-mirror.png" alt-text="Diagram shows volumes labeled data and copy connected by circular arrows and both volumes are associated with a bank of disks in servers.":::
 
 Nested resiliency provides data resiliency between servers with two-way mirroring, then adds resiliency within a server with two-way mirroring or mirror-accelerated parity. Nesting provides data resilience even when one server is restarting or unavailable. Its storage efficiency is 25 percent with nested two-way mirroring and around 35-40 percent for nested mirror-accelerated parity. Nested resiliency can safely tolerate two hardware failures at a time (two drives, or a server and a drive on the remaining server). Because of this added data resilience, we recommend using nested resiliency on production deployments of two-server clusters. For more info, see [Nested resiliency](/windows-server/storage/storage-spaces/nested-resiliency).
 
@@ -67,15 +67,15 @@ Nested resiliency provides data resiliency between servers with two-way mirrorin
 
 With three servers, you should use three-way mirroring for better fault tolerance and performance. Three-way mirroring keeps three copies of all data, one copy on the drives in each server. Its storage efficiency is 33.3 percent – to write 1 TB of data, you need at least 3 TB of physical storage capacity in the storage pool. Three-way mirroring can safely tolerate [at least two hardware problems (drive or server) at a time](/windows-server/storage/storage-spaces/storage-spaces-fault-tolerance#examples). If 2 nodes become unavailable the storage pool loses quorum, since 2/3 of the disks aren't available, and the virtual disks are unaccessible. However, a node can be down and one or more disks on another node can fail and the virtual disks remain online. For example, if you're rebooting one server when suddenly another drive or server fails, all data remains safe and continuously accessible.
 
-:::image type="content" source="media/plan-volumes/three-way-mirror.png" alt-text="Diagram shows a volume labeled data and two labeled copy connected by circular arrows with each volume associated with a server containing physical disks." lightbox="media/plan-volumes/three-way-mirror.png":::
+:::image type="content" source="media/plan-volumes/three-way-mirror.png" alt-text="Diagram shows a volume labeled data and two labeled copy connected by circular arrows with each volume associated with a server containing physical disks.":::
 
 ### With four or more servers
 
 With four or more servers, you can choose for each volume whether to use three-way mirroring, dual parity (often called "erasure coding"), or mix the two with mirror-accelerated parity.
 
 Dual parity provides the same fault tolerance as three-way mirroring but with better storage efficiency. With four servers, its storage efficiency is 50.0 percent; to store 2 TB of data, you need 4 TB of physical storage capacity in the storage pool. This increases to 66.7 percent storage efficiency with seven servers, and continues up to 80.0 percent storage efficiency. The tradeoff is that parity encoding is more compute-intensive, which can limit its performance.
 
-:::image type="content" source="media/plan-volumes/dual-parity.png" alt-text="Diagram shows two volumes labeled data and two labeled parity connected by circular arrows with each volume associated with a server containing physical disks." lightbox="media/plan-volumes/dual-parity.png":::
+:::image type="content" source="media/plan-volumes/dual-parity.png" alt-text="Diagram shows two volumes labeled data and two labeled parity connected by circular arrows with each volume associated with a server containing physical disks.":::
 
 Which resiliency type to use depends on the performance and capacity requirements for your environment. Here's a table that summarizes the performance and storage efficiency of each resiliency type.
 
@@ -129,15 +129,15 @@ Size is distinct from volume's *footprint*, the total physical storage capacity
 
 The footprints of your volumes need to fit in the storage pool.
 
-:::image type="content" source="media/plan-volumes/size-versus-footprint.png" alt-text="Diagram shows a 2 TB volume compared to a 6 TB footprint in the storage pool with a multiplier of three specified." lightbox="media/plan-volumes/size-versus-footprint.png":::
+:::image type="content" source="media/plan-volumes/size-versus-footprint.png" alt-text="Diagram shows a 2 TB volume compared to a 6 TB footprint in the storage pool with a multiplier of three specified.":::
 
 ### Reserve capacity
 
 Leaving some capacity in the storage pool unallocated gives volumes space to repair "in-place" after drives fail, improving data safety and performance. If there's sufficient capacity, an immediate, in-place, parallel repair can restore volumes to full resiliency even before the failed drives are replaced. This happens automatically.
 
 We recommend reserving the equivalent of one capacity drive per server, up to 4 drives. You may reserve more at your discretion, but this minimum recommendation guarantees an immediate, in-place, parallel repair can succeed after the failure of any drive.
 
-:::image type="content" source="media/plan-volumes/reserve.png" alt-text="Diagram shows a volume associated with several disks in a storage pool and unassociated disks marked as reserve." lightbox="media/plan-volumes/reserve.png":::
+:::image type="content" source="media/plan-volumes/reserve.png" alt-text="Diagram shows a volume associated with several disks in a storage pool and unassociated disks marked as reserve.":::
 
 For example, if you have 2 servers and you're using 1 TB capacity drives, set aside 2 x 1 = 2 TB of the pool as reserve. If you have 3 servers and 1 TB capacity drives, set aside 3 x 1 = 3 TB as reserve. If you have 4 or more servers and 1 TB capacity drives, set aside 4 x 1 = 4 TB as reserve.
 

WindowsServerDocs/storage/storage-spaces/storage-spaces-direct-overview.md

@@ -4,7 +4,7 @@ ms.author: cosdar
 manager: dongill
 ms.topic: article
 author: cosmosdarwin
-ms.date: 01/03/2025
+ms.date: 02/11/2025
 ms.assetid: 8bd0d09a-0421-40a4-b752-40ecb5350ffd
 description: An overview of Storage Spaces Direct, a feature of Windows Server and Azure Stack HCI that enables you to cluster servers with internal storage into a software-defined storage solution.
 ---
@@ -45,7 +45,7 @@ In these volumes, you can place your files, such as .vhd and .vhdx for VMs. You
 
 The following section describes the features and components of a Storage Spaces Direct stack.
 
-:::image type="content" source="media/storage-spaces-direct-overview/converged-full-stack.png" alt-text="Storage Spaces Direct Stack." lightbox="media/storage-spaces-direct-overview/converged-full-stack.png":::
+:::image type="content" source="media/storage-spaces-direct-overview/converged-full-stack.png" alt-text="Storage Spaces Direct Stack.":::
 
 **Networking Hardware.** Storage Spaces Direct uses SMB3, including SMB Direct and SMB Multichannel, over Ethernet to communicate between servers. We strongly recommend using 10+ GbE with remote-direct memory access (RDMA), either iWARP or RoCE.
 
@@ -102,13 +102,13 @@ Storage Spaces Direct supports the following two deployment options:
 
 In a hyperconverged deployment, you use single cluster for both compute and storage. The hyperconverged deployment option runs Hyper-V virtual machines or SQL Server databases directly on the servers providing the storage—storing their files on the local volumes. This eliminates the need to configure file server access and permissions, which in turn reduces hardware costs for small-to-medium business and remote or branch office deployments. To deploy Storage Spaces Direct on Windows Server, see [Deploy Storage Spaces Direct on Windows Server](/windows-server/storage/storage-spaces/deploy-storage-spaces-direct). To deploy Storage Spaces Direct as part of Azure Stack HCI, see [What is the deployment process for Azure Stack HCI?](/azure-stack/hci/deploy/operating-system)
 
-:::image type="content" source="media/storage-spaces-direct-overview/hyper-converged-minimal.png" alt-text="[Storage Spaces Direct serves storage to Hyper-V VMs in the same cluster.]" lightbox="media/storage-spaces-direct-overview/hyper-converged-minimal.png":::
+:::image type="content" source="media/storage-spaces-direct-overview/hyper-converged-minimal.png" alt-text="Storage Spaces Direct serves storage to Hyper-V VMs in the same cluster.":::
 
 ### Converged deployment
 
 In a converged deployment, you use separate clusters for storage and compute. The converged deployment option, also known as 'disaggregated,' layers a Scale-out File Server (SoFS) atop Storage Spaces Direct to provide network-attached storage over SMB3 file shares. This allows for scaling compute and workload independently from the storage cluster, essential for larger-scale deployments such as Hyper-V IaaS (Infrastructure as a Service) for service providers and enterprises.
 
-:::image type="content" source="media/storage-spaces-direct-overview/converged-minimal.png" alt-text="Storage Spaces Direct serves storage using the Scale-Out File Server feature to Hyper-V VMs in another server or cluster." lightbox="media/storage-spaces-direct-overview/converged-minimal.png":::
+:::image type="content" source="media/storage-spaces-direct-overview/converged-minimal.png" alt-text="Storage Spaces Direct serves storage using the Scale-Out File Server feature to Hyper-V VMs in another server or cluster.":::
 
 ## Manage and monitor
 
@@ -145,7 +145,7 @@ There are [over 10,000 clusters](https://techcommunity.microsoft.com/t5/storage-
 
 Visit [Microsoft.com/HCI](https://www.microsoft.com/hci) to read their stories.
 
-:::image type="content" source="media/storage-spaces-direct-overview/customer-stories.png" alt-text="Grid of customer logos." link="https://azure.microsoft.com/products/azure-stack/hci/" lightbox="media/storage-spaces-direct-overview/customer-stories.png":::
+<!-->:::image type="content" source="media/storage-spaces-direct-overview/customer-stories.png" alt-text="Grid of customer logos." link="https://azure.microsoft.com/products/azure-stack/hci/":::-->
 
 ## Additional references
 

includes/create-volumes-with-nested-resiliency.md

@@ -2,7 +2,7 @@
 author: ManikaDhiman
 ms.author: v-manidhiman
 ms.topic: include
-ms.date: 01/23/2025
+ms.date: 02/11/2025
 ---
 
 You can use familiar storage cmdlets in PowerShell to create volumes with nested resiliency, as described in the following section.
@@ -12,21 +12,24 @@ You can use familiar storage cmdlets in PowerShell to create volumes with nested
 Windows Server 2019 requires you to create new storage tier templates using the `New-StorageTier` cmdlet before creating volumes. You only need to do this once, and then every new volume you create can reference these templates.
 
 > [!NOTE]
-> If you're running Windows Server 2022, Azure Stack HCI 21H2, or Azure Stack HCI 20H2, you can skip this step.
+> If you're running Windows Server 2022, Azure Stack HCI, version 21H2, or Azure Stack HCI, version 20H2, you can skip this step.
 
 Specify the `-MediaType` of your capacity drives and, optionally, the `-FriendlyName` of your choice. Don't modify other parameters.
 
 For example, if your capacity drives are hard disk drives (HDD), launch PowerShell as Administrator and run the following cmdlets.
 
 To create a NestedMirror tier:
 
-```PowerShell
+```powershell
 New-StorageTier -StoragePoolFriendlyName S2D* -FriendlyName NestedMirrorOnHDD -ResiliencySettingName Mirror -MediaType HDD -NumberOfDataCopies 4
 ```
+
 To create a NestedParity tier:
+
 ```powershell
 New-StorageTier -StoragePoolFriendlyName S2D* -FriendlyName NestedParityOnHDD -ResiliencySettingName Parity -MediaType HDD -NumberOfDataCopies 2 -PhysicalDiskRedundancy 1 -NumberOfGroups 1 -FaultDomainAwareness StorageScaleUnit -ColumnIsolation PhysicalDisk
 ```
+
 If your capacity drives are solid-state drives (SSD), set the `-MediaType` to `SSD` instead and change the `-FriendlyName` to `*OnSSD`. Don't modify other parameters.
 
 > [!TIP]
@@ -64,7 +67,7 @@ Volumes that use nested resiliency appear in [Windows Admin Center](/windows-ser
 
 ### Optional: Extend to cache drives
 
-With its default settings, nested resiliency protects against the loss of multiple capacity drives at the same time, or one server and one capacity drive at the same time. To extend this protection to [cache drives](/azure-stack/hci/concepts/cache), there's another consideration: because cache drives often provide read and write caching for multiple capacity drives, the only way to ensure you can tolerate the loss of a cache drive when the other server is down is to not cache writes, but that impacts performance.
+With its default settings, nested resiliency protects against the loss of multiple capacity drives at the same time, or one server and one capacity drive at the same time. To extend this protection to [cache drives](../WindowsServerDocs/storage/storage-spaces/cache.md), there's another consideration: because cache drives often provide read and write caching for multiple capacity drives, the only way to ensure you can tolerate the loss of a cache drive when the other server is down is to not cache writes, but that impacts performance.
 
 To address this scenario, Storage Spaces Direct offers the option to automatically disable write caching when one server in a two-server cluster is down, and then re-enable write caching once the server is back up. To allow routine restarts without performance impact, write caching isn't disabled until the server has been down for 30 minutes. Once write caching is disabled, the contents of the write cache is written to capacity devices. After this, the server can tolerate a failed cache device in the online server, though reads from the cache might be delayed or fail if a cache device fails.