And just so you know, this will also upgrade ReFS version of existing volumes to v3.7, so you cannot go back to Windows 2019.
As it happens, one of the first things we did, was to delete some old/archived Veeam backup chains.
And what should I say - it seems as slow as before, but also just "killed" our server
Well, let's go into some details...
We have two independent volumes of ~50TB in this server and deleted like 10TB of Veeam backups on each at more or less the same time.
We checked progress (i.e. looking on how fast disk space was released) and after 2-3 minutes the system just crashed with a bluescreen on "refs.sys - thread exception not handled" message.
Unfortunately, the server would also no longer start after that, as on bootup it just locks up again with the same message and reboots itself. (I assume this happens the moment when Windows tries to auto-mount these ReFS volumes during startup)
After several unsuccessful tries to somehow boot up Windows again with save boot or repair options, we then disabled these ReFS volumes on the RAID controller.
Somewhat unsurprisingly, Windows did now start up again without any issues.
After checking the volume consistency and everything else we thought of, we enabled these volumes again one after the other.
And while one of them works without any issues, as soon as we enable the other and Windows tries to access it --> refs.sys bluescreen and system reboot
At the moment we are still looking into options of recovering the data from this obviously corrupted ReFS filesystem.
Of course we are also quite surprised that Windows would lockup/reboot (and be caught in a loop) when such a filesystem corruption on a non-system volume occurs.
Well, our "incident" may be pure (bad) luck and have nothing to do with Windows 2022/ReFS 3.7, but at the moment we ceased on all plans to upgrade or install Windows 2022 where ReFS is involved.
