Forum Discussion
b26063 - Bug Bash - Enabling the new ReFS Dedup will fail - not enough space on the disk
Tried to follow the instructions on non CSV ReFS drive but ReFSDedup with Dedup or DedupandCompression will fail on non CSV drives with ReFS.
ReFS Version is 3.14, Clustersize 64k
what I have tried:
emptied the drive
reformatted the drive, still 3.14.
expected behaviour:
since the new dedup is going to replace the old dedup I hoped that this would work with any types of ReFS drives, not eventually limited to CSV, as the bug bash task requests.
- Curiosity: What is the difference between ReFSDedup and "normal" dedup on ReFS? I've testet the latter version with my "dedup corruption" issue. My search-engine fu fails here to give useful information with actual technical details about the differences besides the "uses block cloning".
I have little experience here Joachim_Otahal as this Dedup (+ Compression) is new approach of Dedup.
Good news activating Dedup in Server Manager / Feature will install the new Dedup as it seems in my lab.
I understood that we had to disable the old dedup (when enabled before 2025, as-is) and then enable the new one.
The new Dedup differs from the old as per announcement of Ignite. It is designed to achieve a higher dedup and lesser CPU utilization. It can handle to dedup write, where as the old did Dedup on time based schedules. That's what I take from the demo at Ignite.
This all is depending on the ReFS version. Unfortunately the otherwise great inoffical document stopped at ReFS 3.9, we are at 3.14 now.Karl-WE Actually compression is part of dedup since Server 2012 (without R2). It is one of the reasons why windows server deduplication quite often beats storage appliances. You can even specify which file extension should never be compressed during deduplication. Try
(Get-DedupVolume).NoCompressionFileTypewhich is still missing 7z in its default set...
