When an offloaded transfer is initiated, Windows uses tokens as point-in-time representations of the data being transferred. Instead of routing data through the host, the token is copied between the source server and the destination server. The source server then delivers the token to the source storage array, which performs the actual copy or move while providing status updates regarding the transfer. Step by step, the process looks like this:

With ODX, data transfers are offloaded when you copy or move data stored on an array, whether you use graphical tools, such as File Explorer, or command-line tools, such as XCOPY. You can verify ODX support by examining the file system filter drivers that are attached to volumes. For each filter driver, query the registry to determine whether the filter driver has opted in to ODX support.

List the filter system drivers for a particular volume by entering the following at an elevated Windows PowerShell prompt:

fltmc instances -v Volume

Here, Volume is the drive designator of the volume to examine, such as:

fltmc instances -v i:

Each filter is listed by name and should have a SprtFtrs value. If the supported features value is 3, the filter driver supports ODX. If this value is not 3, the filter driver doesn’t support ODX and you need to obtain a different driver from the vendor.

If the SprtFtrs value isn’t as expected, you also can go into the registry to confirm support. At an elevated Windows PowerShell prompt, enter:

get-itemproperty hklm:systemcurrentcontrolsetservicesfiltername
-name "SupportedFeatures"

Here, FilterName is the name of the filter, as listed by Fltmc. Again, if the supported features value is 3, the filter driver supports ODX. If this value is not 3, the filter driver doesn’t support ODX, and you need to obtain a different driver from the vendor.

You can enable ODX support by entering the following at an elevated Windows PowerShell prompt:

set-itemproperty hklm:systemcurrentcontrolsetcontrolfilesystem
-name "FilterSupportedFeaturesMode" -value 0

Disable ODX support by entering the following:

set-itemproperty hklm:systemcurrentcontrolsetcontrolfilesystem
-name "FilterSupportedFeaturesMode" -value 1

As Figure 17-1 shows, the File And Storage Services node has multiple subnodes. The Volumes subnode lists allocated storage on each server according to how volumes are provisioned and how much free space each volume has. Volumes are listed regardless of whether the underlying disks are physical or virtual.

Press and hold or right-click a volume to display management options, including the following:

Figure 17-1. View available storage volumes.

The Disks subnode, shown in Figure 17-2, lists the disks available to each server according to total capacity, unallocated space, partition style, subsystem, and bus type. Server Manager attempts to differentiate between physical disks and virtual disks by showing the virtual disk label (if one was provided) and the originating storage subsystem. Press and hold or right-click a disk to display management options, including the following:

Figure 17-2. View available disks and storage allocation.

The version of Storage Spaces that ships with Windows Server 2012 R2 is different from the version that ships with Windows Server 2012. If you have any questions about which version of Storage Spaces is being used, press and hold or right-click the storage pool you want to examine and then select Properties. In the Properties dialog box, select Details in the left pane and then choose Version on the Property selection list.

Storage pool details also provide details about capacity, status, logical sector size, physical sector size, provisioned space size, thin provisioning alert threshold, and total used space. By default, Storage Space alerts you when storage is approaching capacity and when a storage space reaches 70 percent of the total provisioned size. When you get such an alert, you should consider allocating additional storage.

You can upgrade the version of Storage Spaces a storage pool uses by pressing and holding or right-clicking a storage pool and then selecting Upgrade Storage Pool Version. In addition to correcting issues that can result in error and warning states when creating and managing Storage Spaces, the Windows Server 2012 R2 version of Storage Spaces has many improvements.

Windows Server 2012 R2 supports storage spaces that have dual parity and parity and dual parity spaces on failover clusters. With dual parity, storage spaces are protected against two simultaneous drive failures. Windows Server 2012 R2 also supports the following:

With automatic rebuild, Windows Server can automatically rebuild storage spaces from storage pool free space instead of having to use hot spares to recover from drive failures. Here, instead of writing a copy of data that was on a failed disk to a hot spare, the parity or mirrored data is copied to multiple drives in the pool to achieve the previous level of resiliency automatically. As a result, you don’t need to allocate hot spares in storage pools specifically, provided that a sufficient number of drives is assigned to the pool to allow for automatic resiliency recovery.

With storage tiers, Windows Server can automatically move frequently used files from slower physical disks to faster solid state drive (SSD) storage. This feature is applicable only when a storage space has a combination of SSD storage and hard disk drive (HDD) storage. In addition, the storage type must be set as fixed, the volumes created on virtual disks must be the same size as the virtual disk, and enough free space must be available to accommodate the preference. For fine-grained management, use the Set-FileStorageTier cmdlet to assign files to standard physical drive storage or faster SSD storage.

When a storage pool uses SSD storage, Windows Server can use write-back caching. Write-back cache buffers small random writes to SSD storage before later writing the data to HDD storage. Buffering writes in this way helps protect against data loss in the event of power failures. For write-back cache to work properly, storage spaces with simple volumes must have at least one SSD, storage spaces with two-way mirroring or single parity must have at least two SSDs, and storage spaces with three-way mirroring or dual parity must have at least three SSDs. When these requirements are met, the volumes automatically use a 1 GB write-back cache by default. You can designate SSDs that should be used for write-back caching by setting the usage as Journal (the default in this configuration). If not enough SSDs are configured for journaling, the write-back cache size is set to 0 (meaning write-back caching will not be used). The only exception is for parity spaces, which then have the write-back cache size set to 32 MB.

If you have any question about the size of the write-back cache, complete the following steps to check the cache size:

You also can use this technique to check allocated size, status, provisioned size, provision type, redundancy type, and more.

Storage Spaces uses physical disks exclusively for data storage. When you add a formatted drive to a storage pool, Windows permanently deletes all the files on that drive.

Storage layers that abstract the physical disk are not compatible with Storage Spaces. These include VHDs, pass-through disks on a virtual machine, and storage subsystems that layer RAID on top of the physical disks. Although Storage Spaces supports SAS, SATA, and USB, Storage Spaces doesn’t currently support iSCSI or Fibre Channel controllers. If RAID adapters are used, the adapters must be in non-RAID mode with RAID functionality disabled and must not abstract the physical disks, cache data, or obscure any attached devices.

In Server Manager, you can work with storage pools and allocate space by selecting the File And Storage Services node and then selecting the related Storage Pools subnode. The Storage Pools subnode, shown in Figure 17-3, lists the available storage pools, the virtual disks created within storage pools, and the available physical disks. Keep in mind that what’s presented as physical disks might actually be LUNs (virtual disks) from a storage subsystem.

Figure 17-3. View available storage pools.

Working with storage pools is a multistep process:

The sections that follow examine procedures related to each of these steps.

You can use storage pools to pool available space on disks so that units of storage (virtual disks) can be allocated from this pool. To create a storage pool, you must have at least one unused disk and a storage subsystem to manage it. This storage subsystem can be the one included with the Storage Spaces feature or a subsystem associated with attached storage.

When a computer has hard drives in addition to the hard drive on which Windows is installed, you can allocate one or more of the additional drives to a storage pool. However, keep in mind that if you use a formatted drive with a storage pool, Windows permanently deletes all the files on that drive. In addition, it’s important to point out that physical disks with the master boot record (MBR) partition style are converted automatically to the GUID partition table (GPT) partition style when you add them to a storage pool and create volumes on them.

As shown in Figure 17-4, each server that has disks that are unallocated but available to be assigned to a storage pool is listed as having a primordial pool. A primordial pool is simply a group of disks managed by and available to a specific server through a storage subsystem. A server must have a primordial pool from which disks can be allocated to create a new storage pool.

Figure 17-4. Primordial pools represent unallocated but available disks.

Each physical disk allocated to the pool can be handled in one of three ways:

If a server has a primordial pool, you can create a storage pool from its unallocated but available disks by completing the following steps:

If any portion of the configuration failed, note the reason for the failure and take corrective actions as appropriate before repeating this procedure.

If one of the physical disks is currently formatted with a volume, you get the following error: “Could not create storage pool. One of the physical disks specified is not supported by this operation.”

This error occurs because physical disks that you want to add to a storage pool cannot contain existing volumes. To resolve the problem, you must repeat the procedure and select a different physical disk or remove any existing volumes on the physical disk, repeat the procedure, and then select the disk again. Keep in mind that deleting a volume permanently erases all data it contains.

If one of the physical disks is unavailable after being selected, you see the “Could not create storage pool. One or more parameter values passed to the method were invalid.” error.This error occurs because a physical disk that was available when you started the New Storage Pool Wizard has become unavailable or is offline. To resolve the problem, you need to (a) repeat the procedure and select a different physical disk or (b) bring the physical disk online or otherwise make it available for use, repeat the procedure, and then select the disk again.

External storage can become unavailable for a variety of reasons. For example, an externally connected cable might have been disconnected or a LUN previously allocated to the server might have been reallocated by a storage administrator.

After you create a storage pool, you can allocate space from the pool to virtual disks that are available to your servers. Each physical disk allocated to the pool can be handled in one of three ways:

You can create several types of volumes on virtual disks, including the following:

Windows Server 2012 and Windows Server 2012 R2 are the first versions of Windows Server to support dual parity volumes and three-way mirrors. Although dual parity does not have a penalty for read operations, it does have a performance penalty for write operations because of the overhead associated with calculating and writing dual parity values. With standard dual parity volumes, the usable capacity of dual parity volumes is calculated as the sum of the number of volumes minus two times the size of the smallest volume in the array, or (N – 2) * MinimumVolumeSize. For example, with 7 volumes and the smallest volume size of 1 TB, the usable capacity typically is 5 TB [calculated as (7 – 2) * 1 TB = 5 TB].

Logically, it would seem that you need at least six drives to have three mirrored copies of data. However, mathematically, you need only five volumes to create a three-way mirror. Why? If you want three copies of your data, you need at least 15 logical units of storage to create those three copies. Divide 15 by 3 to come up with the number of disks required, and the answer is that you need five disks. Thus, Storage Spaces uses one-third of each disk to store original data and two-thirds of each disk to store copies of data. Following this, a three-way mirror with five volumes has a two-thirds (66.66 percent) overhead for redundancy. Put another way, you could allocate five 3 TB drives as a three-way mirror, giving you 5 TB of mirrored storage (and 10 TB of overhead).

With single parity volumes, data is written out horizontally with parity calculated for each row of data. Dual parity differs from single parity in that row data is stored not only horizontally but also diagonally. If a single disk fails or a read error from a bad bit or block error occurs, the data is re-created by using only the horizontal row parity data (just as in single parity volumes). In the case of a multiple drive issue, the horizontal and diagonal row data are used for recovery.

Consider the following simplified example as a way to understand better how dual parity typically works:

When a storage pool has a single disk, your only option for allocating space on that disk is to create virtual disks with a simple layout. A simple layout does not protect against disk failure. If a storage pool has multiple disks, you use mirroring or parity to protect data in case of error or failure.

With a mirror layout, data is duplicated on disks by using a mirroring technique similar to what I discussed previously in this chapter. However, the mirroring technique is more sophisticated in that data is mirrored onto two or three disks at a time. Like standard mirroring, this approach has its advantages and disadvantages. Here, if a storage space has two or three disks, you are fully protected against a single disk failure and, if a storage space has five or more disks, you are fully protected against two simultaneous disk failures. The disadvantage is that mirroring reduces capacity by up to 50 percent. For example, if you mirror two 2 TB disks, the usable space is 2 TBs.

With a parity layout, data and parity information are striped across physical disks by using a striping-with-parity technique similar to what I discussed previously in this chapter. Like standard striping with parity, this approach has its advantages and disadvantages. You need at least three disks to protect yourself fully against a single disk failure. You lose some capacity to the striping but not as much as with mirroring. For example, if you enable parity on three 2 TB disks, the usable space is 4 TBs.

You can create a virtual disk in a storage pool by completing the following steps:

Keep in mind that if there aren’t enough available disks to implement the storage layout you choose when creating a virtual disk, you get the following error: “The storage pool does not contain enough physical disks to support the selected storage layout.” Here, select a different layout or repeat this procedure and select a different storage pool to work with initially. Keep in mind that the storage pool might have one or more disks allocated as hot spares. Hot spares are made available automatically to recover from disk failure when you use mirroring or parity volumes—and cannot otherwise be used.

To force Windows to use a hot spare, you can remove the hot spare from the storage pool by pressing and holding or right-clicking it and selecting Remove and then adding the drive back to the storage pool as an automatically allocated disk by pressing and holding or right-clicking the storage pool and selecting Add Physical Drive. Unfortunately, doing so might cause a storage pool created with a hot spare to report that it is in an Unhealthy state. If you subsequently try to add the drive again in any capacity, you get an error stating, “Error adding task: The storage pool could not complete the operation because its configuration is read-only.” The storage pool is not, in fact, in a read-only state. If the storage pool were in a read-only state, you could enter the following command at an elevated Windows PowerShell prompt to clear this state:

Get-Storagepool "PoolName" | Set-Storagepool -IsReadonly $false

However, entering this command likely will not resolve the problem. To clear this error, I needed to reset Storage Spaces and the related subsystem. You might find it easier just to restart the server. After you reset or restart the server, the storage pool transitions from an error state (where a red circle with an x is showing) to a warning state (where a yellow triangle with an ! is showing). You can then remove the physical disk from the storage pool by pressing and holding or right-clicking it and selecting Remove. Afterward, you can add the physical disk as an automatically allocated disk by pressing and holding or right-clicking the storage pool and selecting Add Physical Drive.

Standard volumes can be created on any physical or virtual disk available. You use the same technique regardless of how the disk is presented to the server. This enables you to create standard volumes on a server’s internal disks, on virtual disks in a storage subsystem available to a server, and on virtual iSCSI disks available to a server. If you add the data deduplication feature to a server, you can enable data deduplication for standard volumes created for that server.

You can create a standard volume by completing the following steps:

Typical problems creating storage spaces and allocating storage were discussed previously. You also might find that a physical disk that should be available for use isn’t available. To add a physical disk that has been detected but isn’t listed as available, complete the following steps:

Alternatively, if the storage system has not detected the physical disk, select Tasks on the Storage Pools panel and then select Rescan Storage.

Other problems you might experience with storage spaces relate to drive failures and a loss of resiliency. When a storage space uses two-way mirroring, three-way mirroring, parity, or dual parity, you can recover resiliency by reconnecting a disconnected drive or replacing a failed drive. When a storage space uses a simple volume and drives were disconnected, you can recover the volume by reconnecting the drives.

Windows Server restores redundancy by copying data as necessary to the new disk. During this process, the status of the storage space normally is listed as Repairing. You also see a value depicting how much of the repair task is completed. When this value reaches 100 percent, the repair is complete.

When storage spaces use external drives, a missing drive might be a common problem you encounter. In this case, users can continue to work and redundancy will be restored when you reconnect the drive. However, if a drive fails, you need to complete the following steps to restore redundancy:

Selecting the notification icon for Action Center displays the related notifications. If there is a problem with storage spaces, Action Center updates the related notification panel in the desktop notification area with a message stating, “Check Storage Spaces for issues.” To open Server Manager, select the notification icon and then select the link provided. In Server Manager, select the File And Storage Services node and then select Storage Pools to get the relevant error and warning icons.

To view errors and warnings for storage pools, press and hold or right-click the storage pool with the error or warning icon and then select Properties. In the Properties dialog box, select Health in the left pane to display the health status and operational status in the main pane. For example, you might find that the health status is listed as Warning and the operation status is listed as Degraded. Degraded is a status you get when there is a loss of redundancy.

To view errors and warnings for virtual disks and their associated physical disks, press and hold or right-click the virtual disk with the error or warning icon and then select Properties. In the Properties dialog box, select Health in the left pane to display the health status and operational status in the main pane. Note the storage layout and the physical disks in use as well. If there is a problem with a physical disk, such as a loss of communication, this status appears. You get a Loss Of Communication status when a physical disk is missing, failed, or disconnected.

File optimization is a key part of data deduplication. Optimization involves the following:

The organized chunks are placed in special container files within the chunk store, which is in the System Volume Information folder. Optimized files on the volume are no longer stored as independent streams. Instead, they are replaced with stubs that point to data blocks within a common chunk store. Because duplicate blocks of data are stored only once within the chunk store, optimized files are transparently assembled during file access, ensuring that users and applications see the correct blocks without any impact or apparent change in behavior.

The integrity of deduplicated data is maintained by using checksum validation on data and metadata. As a further safeguard against corruption, Windows maintains redundant copies of all metadata and the most frequently referenced data. With these safeguards included, the result of optimization is up to 2:1 storage savings for standard data and up to 20:1 storage savings for VHD data.

Data deduplication is for primary data volumes and not for boot, system, or other specialized types of volumes. Ideally, you use data deduplication for primary data volumes that have the following:

As part of deduplication, the chunk store is optimized periodically. The default optimization occurs in the background. In addition to periodic optimization, Windows performs garbage collection and data scrubbing periodically. By default, garbage collection and data scrubbing occur weekly at a specified time. Use the Get-DedupSchedule cmdlet to determine the specific times.

ddpeval VolumeOrPath

Data chunks in the chunk store are compressed for most file types by default. File types that aren’t compressed in the chunk store include those that are already compressed and those that chunk compression might adversely affect, such as audio and video files. There might be file types that you don’t want deduplicated, and you can specify these file types as exclusions. To exclude specific types of files, you need to specify that they shouldn’t be included.

Files that are exclusively open for write operations, updated frequently, or heavily accessed aren’t good candidates for deduplication because the frequent updates and high access levels cancel the optimization gains. Therefore, use deduplication on volumes with files that aren’t constantly being updated or accessed. You’ll have better results with these less-utilized volumes.

File age policies can be used to control when files are deduplicated, and this will help reduce early or frequent deduplication of files that are modified regularly. That said, you can configure deduplication to process files that are 0 days old. Deduplication will continue, but it still won’t optimize files that are heavily accessed or exclusively open for write operations. Files must be closed when optimization tasks run.

You can enable deduplication on empty volumes and volumes that already contain data. Windows Server 2012 R2 deduplicates data on a single volume at a rate of approximately 10 MBs to 40 MBs per second, depending on server activity levels and capacity, which is approximately 50 GBs to 200 GBs per hour. To ensure that the server doesn’t run out of resources, the operating system pauses deduplication if available CPU and memory resources run low.

Deduplication works with BranchCache, distributed file system (DFS) replication, and failover clusters, but it doesn’t work with hard quotas on volume root folders. In Windows Server 2012 R2, BranchCache and deduplication are designed to work together. Deduplicated files are indexed and hashed, so requests for data can be quickly computed and deduplicated data can be transferred more quickly over the network.

Similarly, with DFS replication, there are performance gains and benefits from interoperability. When files are optimized or unoptimized, replication isn’t triggered because the files themselves do not change. Although DFS continues to use Remote Differential Compression (RDC) rather than the chunks in the chunk store for network transfer optimization, files on the DFS replica also can be optimized by using deduplication as long as the replica is running Windows Server 2012 R2.

With failover clusters, each node that accesses deduplicated volumes must have the feature enabled. If so, deduplicated volumes failover gracefully like any other volume. In addition, when a cluster is formed, deduplication schedules are put into the schedule for the cluster. As a result, if a deduplicated volume fails over to another node, the scheduled deduplication task runs as expected at the next scheduled run-time.

When you are using File Server Resource Manager (FRSM) quotas, you can’t create hard quotas on the root folder of a volume that is deduplicated. If a volume has a hard quota on its root folder, the actual free space and the quota-restricted space won’t match, which might cause deduplication optimization jobs to fail. You can, however, create soft quotas on the root folder of a volume. With soft quotas, FSRM uses the logical size of files for enforcing quotas. As a result, quota usage and any quota thresholds are based on the original size of files rather than on the optimized size.

When backing up deduplicated volumes, keep in mind that the technology is supported by block-based backup applications, such as Windows Server Backup. These applications should be able to back up deduplicated data and maintain the optimization in the backup media.

However, file-based backup operations might not support deduplication. As a result, file-based backup operations, such as XCOPY, typically copy files in their original form. Files are transparently assembled in memory during the backup copy operation. Because the deduplication is not retained, the backup target must be large enough to hold the full, original size of the entire data set.

Before you enable data deduplication on volumes, you should consider the types of files that you don’t want compressed as part of data deduplication. Typically, this includes file types that are already compressed. Because data deduplication can be applied using background optimization, throughput optimization, or both, you should consider how and when you want servers to deduplicate volumes.

Servers perform background optimization when they’re otherwise idle. Background optimization runs at low priority and is paused whenever the server isn’t idle. This pause and resume behavior continues until volumes are fully optimized.

Servers perform throughput optimization according to a specific schedule, such as every day at 1:45 A.M. for 6 hours. Throughput optimization runs at normal priority and uses system resources to maximize the optimization process. When started, optimization continues until it completes or reaches the specified duration value.

You can enable and configure data deduplication as part of the volume-creation process by completing the following steps:

Figure 17-9. Set the deduplication type and schedule.

You don’t have to enable deduplication when you create volumes. You can enable and manage data deduplication at any time. With the Volumes subnode selected in Server Manager, press and hold or right-click the volume that you want to manage and then select Configure Data Deduplication. As Figure 17-10 shows, the available configuration options are nearly identical to those discussed previously. The exception is that you now can specify folders to exclude. When you exclude a folder, all contents of the folder are excluded from deduplication, including both files and subfolders and their contents. Specify a folder to exclude by tapping or clicking Add, using the dialog box provided to choose a folder to exclude, and then tapping or clicking Select Folder.

Figure 17-10. Configure deduplication settings for the volume.

When you add the Data Deduplication role service to a server, related Windows PowerShell cmdlets are installed as well. You can use these cmdlets, as mentioned previously, to track the status of deduplication, determine space savings on volumes, and more. You need to use an elevated Windows PowerShell prompt.

Use Get-DedupStatus to display the status of deduplication for each enabled volume. In the following example, you check deduplication on FileServer28 and FileServer32:

Invoke-command -computername fileserver28, fileserver32
-scriptblock {Get-DedupStatus}

As shown here, the output shows how much free space is available, how much space was saved using deduplication, the number of optimized files, and the number of in-policy files:

FreeSpace   SavedSpace   OptimizedFiles   InPolicyFiles    Volume   PSComputerName
--------    ----------   --------------   -------------    ------   FileServer28
325.55 GB   402.22 GB    32581            32588            I: -     FileServer28
98.82 GB    118.75 GB    29812            28714            K: -     FileServer32

You can get more detailed information by formatting the output as a list, as shown here:

Get-DedupStatus | fl

The information provided for each volume is then much more detailed, as shown in this example for the I volume:

Volume                             : I:
VolumeId                           : \?Volume{}
Capacity                           : 466 GB
FreeSpace                          : 325.55 GB
UsedSpace                          : 220.62 GB
UnoptimizedSize                    : 722.68 GB
SavedSpace                         : 502.22 GB
SavingsRate                        : 73 %
OptimizedFilesCount                : 32581
OptimizedFilesSize                 : 685.32 GB
OptimizedFilesSavingsRate          : 78 %
InPolicyFilesCount                 : 32588
InPolicyFilesSize                  : 699.87 GB
LastOptimizationTime               : 9/26/2014 5:32:31 AM
LastOptimizationResult             : 0x00000000
LastOptimizationResultMessage      : The operation completed successfully.
LastGarbageCollectionTime          : 9/26/2014 5:33:01 PM
LastGarbageCollectionResult        : 0x00000000
LastGarbageCollectionResultMessage : The operation completed successfully.
LastScrubbingTime                  : 9/26/2014 6:33:01 AM
LastScrubbingResult                : 0x00000000
LastScrubbingResultMessage         : The operation completed successfully.

Use Get-DedupVolume to examine volume-level deduplication. In the following example, you check volume-level deduplication on FileServer28 and FileServer32:

Invoke-command -computername fileserver28, fileserver32
-scriptblock {Get-DedupVolume}

As shown here, the output shows the status of deduplication on volumes, how much space was saved using deduplication, and the savings rate:

Enabled     SavedSpace         SavingsRate         Volume     PSComputer
-------     ----------         -----------         ------
True        502.22 GB          73 %                I:         FileServer28
True        118.75 GB          58 %                K:         FileServer32

You can get more detailed information by formatting the output as a list, as shown here:

Get-DedupVolume | fl

The information provided for volume-level deduplication is then much more detailed, as shown in this example for the I volume:

Volume                             : I:
VolumeId                           : \?Volume{}
Enabled                            : True
DataAccessEnabled                  : True
Capacity                           : 466 GB
FreeSpace                          : 325.55 GB
UsedSpace                          : 220.62 GB
UnoptimizedSize                    : 722.68 GB
SavedSpace                         : 502.22 GB
SavingsRate                        : 73 %
MinimuFileAgeDays                  : 5
MinimumFileSize                    : 32768
NoCompress                         : False
ExcludeFolder                      : {avi}
ExcludeFileType                    :
NoCompressionFileType              : {aac, aif, aiff, asf...}
ChunkRedundancyThreshold           : 100
Verify                             : False

By using Get-DedupMetadata, you can get detailed information about how deduplication processed files, which includes the number of chunks in the chunk store, the number of StreamMaps, and the number of hotspots. Hotspots are the most frequently referenced chunks. Enter the following command:

Get-DedupMetadata | fl

You see output similar to the following for each volume that uses deduplication:

Volume                         : I:
VolumeId                       : \?Volume{}
StoreId                        : { }
DataChunkCount                 : 4082133
DataContainerCount             : 192
DataChunkAverageSize           : 58.21 KB
DataChunkMedianSize            : 0 B
DataStoreUncompactedFreespace  : 0 B
StreamMapChunkCount            : 36424
StreamMapContainerCount        : 18
StreamMapAverageDataChunkCount :
StreamMapMedianDataChunkCount  :
StreamMapMaxDataChunkCount     :
HotspotChunkCount              : 12422
HotspotContainerCount          : 1
HotspotMedianReferenceCount    :
CorruptionLogEntryCount        : 0
TotalChunkStoreSize            : 182.5 GB

Finally, you can use Get-DedupSchedule to examine the deduplication schedule. As shown here, the output depicts the start time of regular optimization tasks and garbage collection and scrubbing:

Enabled   Type               StartTime   Days           Name
-------   ----               ---------   ----           ----
True      Optimization                                  BackgroundOptimization
True      Optimization       1:45 AM     {Sunday, Monday... ThroughputOptimization
True      Optimization       9:00 AM     {Sunday, Monday... ThroughputOptimization-2
True      GarbageCollection  2:45 AM     Saturday       WeeklyGarbageCollection
True      Scrubbing          3:45 AM     Saturday       WeeklyScrubbing