The slab consolidation / trim operation cannot be performed because the volume alignment is inva

[A-R]

Hello All,

I am seeing some strange behavior in Windows which I cannot seem to figure out. I am posting here hoping that an expert can assist me with this issue.

When provisioning a VM on a VVOL datastore using any Nimble performance policy with a block size other than 4k, Windows cannot automatically optimize the volume. I recieve the message: "The slab consolidation / trim operation cannot be performed because the volume alignment is invalid. (0x89000029)". However, I am able to successfully defrag and retrim the volume using defrag.exe.

Here is the environment:

• VMware ESXi 6.7u2, Dell-Custom image DellEMC-ESXi-6.7U2-13981272-A02
• Nimble CS300 running 5.0.7.200-612527-opt
• VVOL Datastore
• VMware Storage Policies used to assign Nimble Performance Policies and Snapshot schedules\retention

Here is the scenario:

Consider a SQL server with 2 disks -- OS disk and Data disk. OS disk is assigned a VMware Storage Policy which calls for Nimble Performance Policy 'VVOL Operating System" -- this policy assigns a 4k Block Size on the Nimble. The in-guest NTFS is also formatted with 4kb block size. The Data disk is assigned a VMware Storage Policy which calls for Nimble Performance Policy "SQL Server 2012" -- this policy assigns an 8k Block Size on the Nimble. The in-guest NTFS is also formatted with an 8kb block size.

When looking in the Disk Defrag GUI, both disks report as 'Thin Provisioned Drive'. The OS disk is able to both 'analyze' and 'optimize' via the GUI. The Data disk states 'Optimization not available' and the buttons to analyze and optimize are both greyed out.

Research the error message that I recieve from defrag.exe CLI, I find that potetionally the Data disk's NTFS parition may be out of alignment with the underlying physical disks sectors, however that does not appear to be the case -- below is some output from fsutil on an affected server:

OS disk -- working normally:

C:\Windows\system32>fsutil fsinfo sectorinfo c:
LogicalBytesPerSector : 512
PhysicalBytesPerSectorForAtomicity : 512
PhysicalBytesPerSectorForPerformance : 512
FileSystemEffectivePhysicalBytesPerSectorForAtomicity : 512
Device Alignment : Aligned (0x000)
Partition alignment on device : Aligned (0x000)
Performs Normal Seeks
Trim Supported
Not DAX capable

C:\Windows\system32>fsutil fsinfo ntfsinfo c:
NTFS Volume Serial Number : 0xaa92c1be92c18f6f
NTFS Version : 3.1
LFS Version : 2.0
Number Sectors : 0x00000000076e3fff
Total Clusters : 0x0000000000edc7ff
Free Clusters : 0x00000000006df6c1
Total Reserved : 0x0000000000001581
Bytes Per Sector : 512
Bytes Per Physical Sector : 512
Bytes Per Cluster : 4096
Bytes Per FileRecord Segment : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length : 0x0000000010640000
Mft Start Lcn : 0x00000000000c0000
Mft2 Start Lcn : 0x0000000000000002
Mft Zone Start : 0x00000000004959e0
Mft Zone End : 0x000000000049e400
Max Device Trim Extent Count : 1
Max Device Trim Byte Count : 0x40000000
Max Volume Trim Extent Count : 1
Max Volume Trim Byte Count : 0x40000000
Resource Manager Identifier : B045E9A4-ADA8-11E9-87D0-ACE3166FFE30

Data disk, not working as expected:

C:\Windows\system32>fsutil fsinfo sectorinfo e:
LogicalBytesPerSector : 512
PhysicalBytesPerSectorForAtomicity : 512
PhysicalBytesPerSectorForPerformance : 512
FileSystemEffectivePhysicalBytesPerSectorForAtomicity : 512
Device Alignment : Aligned (0x000)
Partition alignment on device : Aligned (0x000)
Performs Normal Seeks
Trim Supported
Not DAX capable

C:\Windows\system32>fsutil fsinfo ntfsinfo e:
NTFS Volume Serial Number : 0xa008f72a08f6fe5a
NTFS Version : 3.1
LFS Version : 2.0
Number Sectors : 0x0000000004fbefff
Total Clusters : 0x00000000004fbeff
Free Clusters : 0x00000000004f5133
Total Reserved : 0x0000000000000200
Bytes Per Sector : 512
Bytes Per Physical Sector : 512
Bytes Per Cluster : 8192
Bytes Per FileRecord Segment : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length : 0x0000000000200000
Mft Start Lcn : 0x0000000000060000
Mft2 Start Lcn : 0x0000000000000001
Mft Zone Start : 0x0000000000060100
Mft Zone End : 0x0000000000066500
Max Device Trim Extent Count : 1
Max Device Trim Byte Count : 0x40000000
Max Volume Trim Extent Count : 1
Max Volume Trim Byte Count : 0x40000000
Resource Manager Identifier : DA93879F-D63C-11E9-B80A-005056A9CF09

So -- both disks report as being properly aligned, and my NTFS cluster size is matching the Nimble's block size for the volume -- yet I cannot retrim or 'optimize' using the Disk Defragment GUI.

Has anyone else experienced this issue and found a solution? I have tried various things such as unmounting/remounting the disks, attaching to different SCSI controllers, etc -- however nothing seems to work unless the Nimble Performance Policy is set to one which uses a 4k block size.

The impact of this issue is that the scheduled ReTrim tasks for Disk Defrag fail to periodically trim the Data disks -- I am having to do this manually on the affected servers, which is something I would like to resolve.

Thanks for reading and for any insight you can offer into this issue.

[NimbleMike]

Consider the following experiment. Mount a new Nimble volume on a Server 2012 R2 host and NTFS format with an 8K cluster. In my scenario, it’s drive E:\. Now attempt to perform a slab consolidation. This is what happens:

C:\>defrag e: /K
Microsoft Drive Optimizer
Copyright (c) 2013 Microsoft Corp.

Invoking slab consolidation on New Volume (E:)...

The slab consolidation / trim operation cannot be performed because the volume alignment is invalid. (0x89000029)

Offline the volume from your 2012 R2 host, change its ACLs to a Server 2019 host, and online. Mount it also as drive E:. Now repeat the slab consolidation. This is what happens:

C:\>defrag e: /K
Microsoft Drive Optimizer
Copyright (c) Microsoft Corp.

Invoking slab consolidation on New Volume (E:)...

Slab consolidation was skipped because there were few evictable slabs.

The operation completed successfully.

Post Defragmentation Report:

Volume Information:
Volume size = 99.99 GB
Free space = 99.90 GB

Slab Consolidation:
Space efficiency = 100%
Recovered space = 0 bytes

Retrim:
Total space trimmed = 96.90 GB

What I’m showing above is that the issue you are seeing is resolved in Server 2019 (actually Server Core 1709 and above).

The defrag.exe utility uses /L to perform a retrim and /K to perform a slab consolidation. /K also causes a retrim to occur after the slab consolidation. The first key point to understand is that slab consolidation is not needed on Nimble volumes. Slab consolidation moves blocks around into larger blocks, the size of the optimal unmap granularity, so that the larger block can be unmapped. Nimble volumes do not require or utilize a large optimal unmap granularity. Slab consolidation is unnecessary.  Windows realizes this and skips slab consolidation on Nimble volumes.

It sounds like what you are interested is a weekly retrim. I should note that even that isn’t really needed. NTFS unmaps blocks automatically, in the background, as files are deleted. The only time a retrim might be helpful is if there was an asynchronous power cycle before NTFS had a chance to flush all its pending unmaps.

If you really want your weekly retrims to work, run Task Scheduler. Go to Task Scheduler Library -> Microsoft -> Windows and select the “ScheduledDefrag” task. Modify the CLI options to perform just a retrim instead of a slab consolidation.  That should resolve your weekly issue.  Just ask youself whether that is even needed.  If not, then you can just disable the weekly disk optimization.