Forum Discussion
26063 deduplication data corruption is still there.
From Server 2022 up to this newest 26063 build, they all have the same problem, as described here: https://techcommunity.microsoft.com/t5/windows-server-insiders/server-vnext-26040-and-server-2022-deduplication-data-corruption/m-p/4047321
I am out of energy for today and give up for today. It seems to be impossible to get Microsoft to care for actual OS bugs instead of marketing.
20 Replies
Build 26080 : Still as easy to reproduce as ever since Server 2022. Without deduplication those VMs update just fine without blue screen and other weirdness.
If there is interest I'll create an 26080 export of the repo from a Server 2019 machine (which should import in Server 2019, Server 2022 and Windows 11 without problems).
MSBernsteinMicrosoft
Thanks, Joachim. I updated the bug report to note that 26080 is included.
MichaelA little update on this: For the first time in many years I had a blue screen on my actual server, which was Server 2019 until mid last year. The first one ever. Bluescreenview from nirsoft lists "ntfs.sys" as culpruit. I unprofessionaly suspect concurrent writes on the deduped volume residing on a tiered mirrored storage space (not S2D). And I unprofessionally suspect that it might be related to the issue with the dedup repo which corrupts data. But only you can tell, not me.
Computer:
i7-4960x, 32 GB RAM (ASRock x79 Fataility). Powersupply a Fujitsu 750 Watt Ex-Primergy.
C: = normal SSD,
😧= Deduped drive. Tiered Storage Space Mirror, 2*SSD, 2*HDD.
E: = Storage Spaces Parity with four drives.
Bitlocker aktive on 😧 and E:
Using NetQoS the speed is limited to 60 MB/s incoming since the tiered storage space cannot write faster. The blue screen happened during three parallel robocopy jobs over network, two of them with 😧 as destination. When the blue screen happened neither a dedupjob, nor a re-tiering job was running according to the event logs. After the crash and the filesystem check I copied linear, not concurrently, on and everything seemed fine.
This is the first ntfs.sys crash I saw anyway since about, maybe, XP SP0?
Here is the dump + the events around that crash.
https://joumxyzptlk.de/tmp/microsoft/NTFS-maybe-dedup-problem-first-server-2022-crash-ever-on-that-computer.7z
- BrentM_MSFTHi, is this NTFS or REFS? Or both?
- NTFS.
- MSBernsteinHi, Joachim. Sorry you are feeling frustrated about this -- we do have a lot of different demands on our time in any given day; we are as human as you are. I work in engineering, not marketing. I'm trying to see if the de-dup team has enough data to diagnose this, given the feedback you've provided.
Thanks,
Michael Bernstein (MSFT)- If you want to look how it plays out with Server 2022 and nVext: I recorded a video which is on my home page https://www.joumxyzptlk.de/tmp/microsoft/S2022-Nested_Deduplication_VDI-Hyperv_profile_kills_filesystem_v2.mp4
Video was created on AMD Ryzen 5950 with Win11 as host, but is the same on Dual Xeon 6226R with Server 2019 (HP ProLiant DL380) as host.- MSBernsteinThanks, Joachim! I attached that video to the bug report to provide additional context for the engineering team.
- Thank you for your reply! The problematic part is actually it applies to Server 2022 too. I can reproduce it with both.