

Seem impossible that somewhere in all of those layers, something was lost in translation and the FS believes it's TRIM'ed a bunch of slabs, but that message never got to the controller itself, or at least not in the right way. Even more interestingly, when the storage spaces virtual disk is made available to a guest VM as a passthrough device, it is identified as a thinly-provisioned LUN. So, to the host, they are SCSI/SAS disks, but they are, in fact, SATA3. These disks are connected to a SAS HBA with SAS-to-SATA breakoutĬables. Specifically, it refers to SCSI and ATA commands to retrieve deleted slabs. The last link you provide is very interesting and something I hadn't seen before. To the opposite, including registry tweaks on how to disable delayed TRIM notifications. I know Hyper-V VHDs don't automatically shrink and you can't do it while online, but are you sure this applies to Storage Spaces virtual disks as well? All the Storage Spaces documentation points You're referring both Storage Spaces and Hyper-V documentation.

Is there an equivalent to optimize-volume -slabconsolidate but at the pool level? It looks lie optimize-storagepool only does rebalancing, but with 100% slab usage there's not much to rebalance so it quits almost immediately. One would think retrim would take care of that, but It's almost as if there's a disconnect between the ReFS and Storage Spaces layers, whereas ReFS "thinks" it has passed the trim instructions on certain blocks, but the pool never received them.

There are only 10TB worth of files on it. The volume still has a 30+ TB footprint even though What I tried over the weekend was optimize-volume -defrag (5 passes, including free space consolidation,) followed by optimize-volume -retrim -slabconsolidate. If I could get a Windows Server 2019 1903 evaluation ISO, I might try dedup, but I don't have an MSDN sub and I see no other way to obtain a copy. I have a Windows 2019 1809 evaluation copy installed on a spare SSD with 170 days to go, but it doesn't even recognize the pool because the metadata was updated by Windows 10 1903. I would love to try dedup but alas this is Windows 10 Pro, not a server SKU.
