Please see other gists for updated information. https://gist.github.com/XenoPanther/15d8fad49fbd51c6bd946f2974084ef8
Last active
December 16, 2024 19:48
-
-
Save 0xbadfca11/da0598e47dd643d933dc to your computer and use it in GitHub Desktop.
Windows ReFS versions
Version number is reported by fsutil fsinfo refsinfo, available on Windows 10 and Windows Server 2016.
- Version of formatted by Windows Server 2012.
- Version 1.1 is used already in Windows Server 8 Beta. I have never seen version 1.0.
- Can use and store alternate data streams, when mount on 8.1/2012 R2 or later.
- Version of formatted by Windows 8.1, Windows 10 v1507 to v1607, Windows Server 2012 R2, and when specified ReFSv1 on Windows Server 2016 or later.
- Cannot use alternate data streams, when mount on 2012.
- Version that can be formatted with Windows 10 Technical Preview build 9841 to 9860 and Windows Server 2016 TP1 (It's not default). Could not mount in 10 9879 or 2016 TP2 and later.
- Version that can be formatted with Windows 10 Technical Preview build 9879 (It's not default). Could not mount in 9926 and later.
- Version that can be formatted with Windows 10 Technical Preview build 9926 (It's not default). Could not mount in 10041 and later.
- Version that can be formatted with Windows 10 Technical Preview build 10041 to 10049 (It's not default). Could not mount in 10061 and later.
- Version of formatted by Windows Server 2016 TP2/TP3.
- Version that can be formatted with between Windows 10 Technical Preview build 10061 or later and earlier than 10130 (It's not default). Could not mount in Windows 10 Insider Preview build 10130 and later, or Windows Server 2016 TP4 and later.
ReFS v2 Overview
http://www.snia.org/sites/default/files/SDC15_presentations/file_sys/JRTipton_ReFS_v2.pdf
http://www.snia.org/events/storage-developer/presentations15#file_sys
- Version of formatted by Windows Server 2016 TP4/TP5.
- Upgrade to 3.1 when writable mount from Windows Server 2016 RTM.
- Version of formatted by Windows Server 2016.
- Version of formatted by Windows 10 v1703.
- Version that can be formatted with Windows 10 Insider Preview 15002 or later (It's not default at 15002) and Windows Server Insider Preview build 16237.
- It became the default between after than 15002 and 15019 or earlier.
- Version of formatted by Windows 10 Enterprise v1709 and Windows Server version 1709.
- Version of formatted by Windows 10 Enterprise Insider Preview build 16257 and Windows Server Insider Preview build 16257.
- Version of formatted by Windows 10 Enterprise v1803, Windows Server 2019 and Windows Server version 1803.
- Version of formatted by Windows 10 Enterprise Insider Preview build 17083 and Windows Server Insider Preview build 17079.
- Version of formatted by Windows 10 Enterprise Insider Preview build 19536 and Windows Server Insider Preview build 19551.
- Added hardlink support if fresh formatted volume.
- Can't use hardlink if upgraded from previous version.
- Upgrade to 3.6 when writable mount from Windows 10 Insider Preview build 21292.
- Version of formatted by Windows 10 Enterprise Insider Preview build 21292 and Windows Server Insider Preview build 20282.
- Upgrade to 3.7 when writable mount from Windows 10 Insider Preview build 21313.
- Version of formatted by Windows 11 Enterprise v21H2 and Windows Server 2022.
- Version of formatted by Windows 10 Enterprise Insider Preview build 21313 and Windows Server Insider Preview build 20303.
- Version of formatted by Windows 11 Enterprise v22H2.
- Version of formatted by Windows 11 Enterprise Insider Preview build 22598 and Windows Server Insider Preview build 25099.
- Added post process compression with LZ4 & ZSTD, transparent decompression.
| ReFS\Windows | 2012 | 8.1/2012 R2 | 10 v1507 | 2016 | 10 v1703 | 10 v1709 | 10 v1803/2019 | 11 v21H2/2022 | 11 v21H2 |
|---|---|---|---|---|---|---|---|---|---|
| 1.1 | Yes | Yes1 | Yes1 | Yes1 | Yes1 | Yes1 | Yes1 | Yes1 | Yes1 |
| 1.2 | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| 3.1 | No | No | No | Yes | Yes2 | Yes3 | Yes4 | Yes56 | Yes76 |
| 3.2 | No | No | Yes | Yes3 | Yes4 | Yes56 | Yes76 | ||
| 3.3 | No | No | Yes | Yes4 | Yes56 | Yes76 | |||
| 3.4 | No | Yes | Yes56 | Yes76 | |||||
| 3.7 | No | Yes | Yes8 | ||||||
| 3.9 | No | Yes |
Notes
Empty filed is "I don't know. I haven't tested.".
License: CC BY
Footnotes
-
"Volume "?:" was mounted in an older version of Windows. Some features may be lost." was recorded to event log when writable mount. I don't know what's been lost. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8
-
Upgrade to 3.2 when writable mount. ↩
-
Upgrade to 3.9 when writable mount. Can't mount read-only. ↩ ↩2 ↩3 ↩4
-
Upgrade to 3.9 when writable mount. ↩
バージョン番号はWindows 10とWindows Server 2016で使用可能なfsutil fsinfo refsinfoで報告されるもの。
- Windows Server 2012でフォーマットしたバージョン。
- Windows Server 8 Betaの時点で1.1であり1.0の存在は不明。
- 8.1/2012 R2以降でマウントした場合はAlternate Data Stream使用可能。
- Windows 8.1、Windows 10 v1507からv1607、Windows Server 2012 R2でフォーマットしたとき、およびWindows Server 2016以降でReFSv1を指定してフォーマットしたときのバージョン。
- 2012でマウントした場合はAlternate Data Stream使用不可。
- Windows 10 TP ビルド9841から9860とWindows Server 2016 TP1でフォーマット可能なバージョン（デフォルトではない）。10 9879/ 2016 TP2以降ではマウント不可。
- Windows 10 TP ビルド9879でフォーマット可能なバージョン（デフォルトではない）。9926以降ではマウント不可。
- Windows 10 TP ビルド9926でフォーマット可能なバージョン（デフォルトではない）。10041以降ではマウント不可。
- Windows 10 TP ビルド10041から10049でフォーマット可能なバージョン（デフォルトではない）。10061以降ではマウント不可。
- Windows Server 2016 TP2/TP3でフォーマットしたバージョン。
- Windows 10 TP ビルド10061から10130より前でフォーマット可能なバージョン（デフォルトではない）。10 10130以降、2016 TP4以降ではマウント不可。
ReFS v2の概要
http://www.snia.org/sites/default/files/SDC15_presentations/file_sys/JRTipton_ReFS_v2.pdf
http://www.snia.org/events/storage-developer/presentations15#file_sys
- Windows Server 2016 TP4/TP5でフォーマットしたバージョン。
- Windows Server 2016から書き込み可能でマウントすると3.1にアップグレードされる。
- Windows Server 2016でフォーマットしたバージョン。
- Windows 10 v1703でフォーマットしたバージョン。
- Windows 10 Insider Preview ビルド15002およびWindows Server Insider Preview ビルド16237でフォーマット可能なバージョン（15002ではデフォルトではない）。
- 15002より後、15019までの間にデフォルトになった。
- Windows 10 Enterprise v1709およびWindows Server version ビルド1709でフォーマットしたバージョン。
- Windows 10 Enterprise Insider Preview ビルド16257およびWindows Server Insider Previewビルド16257でフォーマットしたバージョン。
- Windows 10 Enterprise v1803、Windows Server 2019およびWindows Server version 1803でフォーマットしたバージョン。
- Windows 10 Enterprise Insider Preview ビルド17083およびWindows Server Insider Preview ビルド17079でフォーマットしたバージョン。
- Windows 10 Enterprise Insider Preview ビルド19536およびWindows Server Insider Previewビルド19551でフォーマットしたバージョン。
- 新規フォーマットした場合に限りハードリンク使用可能。
- 3.5未満からアップグレードした場合は使用不可。
- Windows 10 Insider Preview ビルド21292から書き込み可能でマウントすると3.6にアップグレードされる。
- Windows 10 Enterprise Insider Preview 21292およびWindows Server Insider Previewビルド20282でフォーマットしたバージョン。
- Windows 10 Insider Preview ビルド21313から書き込み可能でマウントすると3.7にアップグレードされる。
- Windows 11 Enterprise v21H2およびWindows Server 2022でフォーマットしたバージョン。
- Windows 10 Enterprise Insider Preview 21313およびWindows Server Insider Previewビルド20303でフォーマットしたバージョン。
- Windows 11 Enterprise v22H2でフォーマットしたバージョン。
- Windows 11 Enterprise Insider Preview 22598およびWindows Server Insider Previewビルド25099でフォーマットしたバージョン。
- LZ4 & ZSTDによる事後圧縮と透過伸長が追加。
| ReFS\Windows | 2012 | 8.1/2012 R2 | 10 v1507 | 2016 | 10 v1703 | 10 v1709 | 10 v1803/2019 | 11 v21H2/2022 | 11 v21H2 |
|---|---|---|---|---|---|---|---|---|---|
| 1.1 | Yes | Yes1 | Yes1 | Yes1 | Yes1 | Yes1 | Yes1 | Yes1 | Yes1 |
| 1.2 | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| 3.1 | No | No | No | Yes | Yes2 | Yes3 | Yes4 | Yes56 | Yes76 |
| 3.2 | No | No | Yes | Yes3 | Yes4 | Yes56 | Yes76 | ||
| 3.3 | No | No | Yes | Yes4 | Yes56 | Yes76 | |||
| 3.4 | No | Yes | Yes56 | Yes76 | |||||
| 3.7 | No | Yes | Yes8 | ||||||
| 3.9 | No | Yes |
空欄は「テストしてないので分かりません」を意味します。
License: CC BY
Footnotes
It is quite unfortunate I cannot give exact versions. After updating to the latest canary from the existing latest canary (no new canary as of writing this), my PC would boot loop several times with a BSOD message involving REFS, so I assumed it was due to the dev drive. In my attempt to stop the looping and get back to normal, I reverted the update and it took me back to Build 26016.rs_prerelease.231208-1532.
It worked fine without any crashes, but windows settings didn't open, start menu didn't open, basically nothing on the taskbar except for Win+X and search worked. So I could open other apps through run, and taskbar icons
After trying all forums, I decided to clean install. That was my only option as the ISO available on device wasn't an insider build and is an early version, 21H2 and so has no dev drive support
After clean installing, I updated to 23606.1000 on the dev channel and my Dev drive is not working and asking for a format and I cannot lose my files
What to do?
I've tried refsutil and it gave the following error
The volume is an unsupported ReFS version. This utility supports versions up to 3.9. Volume is 3.12.
It is quite unfortunate I cannot give exact versions. After updating to the latest canary from the existing latest canary (no new canary as of writing this), my PC would boot loop several times with a BSOD message involving REFS, so I assumed it was due to the dev drive. In my attempt to stop the looping and get back to normal, I reverted the update and it took me back to Build 26016.rs_prerelease.231208-1532.
It worked fine without any crashes, but windows settings didn't open, start menu didn't open, basically nothing on the taskbar except for Win+X and search worked. So I could open other apps through run, and taskbar icons
After trying all forums, I decided to clean install. That was my only option as the ISO available on device wasn't an insider build and is an early version, 21H2 and so has no dev drive support
After clean installing, I updated to 23606.1000 on the dev channel and my Dev drive is not working and asking for a format and I cannot lose my files
What to do?
I've tried refsutil and it gave the following error The volume is an unsupported ReFS version. This utility supports versions up to 3.9. Volume is 3.12.
This is an unfortunate news, but don't worry, your data is safe. Build 26002 introduced ReFS 3.12, but Build 23606 only supports the old version of ReFS, which is not backward compatible. Since you used the dev drive on Build 26016, the dev drive uses ReFS 3.12, so you cannot access it on Build 23606. There's two solutions: The first is that you should try to reinstall Build 26002 or Build 26016, as Build 26002 is the first version to provide ReFS 3.12. If it can start, then you can directly access the dev drive. The second method requires more complex operations. I suggest using it only when the first solution is not feasible. First, you need to create an installation USB drive for Build 26002 or Build 26016 (a third-party WindowsPE startup disk with a graphical interface is also feasible), and then prepare a storage device that is large enough to contain all the files you want to keep. Then boot from this USB drive, press shift+f10 at the Windows installation program, a cmd window will open. At this point, you can use cmd to access the dev drive and transfer the files from the dev drive to the backup device.
It is quite unfortunate I cannot give exact versions. After updating to the latest canary from the existing latest canary (no new canary as of writing this), my PC would boot loop several times with a BSOD message involving REFS, so I assumed it was due to the dev drive. In my attempt to stop the looping and get back to normal, I reverted the update and it took me back to Build 26016.rs_prerelease.231208-1532.
It worked fine without any crashes, but windows settings didn't open, start menu didn't open, basically nothing on the taskbar except for Win+X and search worked. So I could open other apps through run, and taskbar icons
After trying all forums, I decided to clean install. That was my only option as the ISO available on device wasn't an insider build and is an early version, 21H2 and so has no dev drive support
After clean installing, I updated to 23606.1000 on the dev channel and my Dev drive is not working and asking for a format and I cannot lose my files
What to do?
I've tried refsutil and it gave the following error The volume is an unsupported ReFS version. This utility supports versions up to 3.9. Volume is 3.12.This is an unfortunate news, but don't worry, your data is safe. Build 26002 introduced ReFS 3.12, but Build 23606 only supports the old version of ReFS, which is not backward compatible. Since you used the dev drive on Build 26016, the dev drive uses ReFS 3.12, so you cannot access it on Build 23606. There's two solutions: The first is that you should try to reinstall Build 26002 or Build 26016, as Build 26002 is the first version to provide ReFS 3.12. If it can start, then you can directly access the dev drive. The second method requires more complex operations. I suggest using it only when the first solution is not feasible. First, you need to create an installation USB drive for Build 26002 or Build 26016 (a third-party WindowsPE startup disk with a graphical interface is also feasible), and then prepare a storage device that is large enough to contain all the files you want to keep. Then boot from this USB drive, press shift+f10 at the Windows installation program, a cmd window will open. At this point, you can use cmd to access the dev drive and transfer the files from the dev drive to the backup device.
Followed through and updated to 26016 again, started to BSOD again with Stop Code REFS_FILE_SYSTEM
I managed to copy my essentials when it wasn't crashing and finally got rid of the partition.
I'm still on 26016 with no failures yet after deleting the dev drive
Thanks @YexuanXiao
Using a refs leads a a huge problem when rolling back windows updates. If they version is updated, you have no way to regain the data but to update to the version you rolled back from
Just chiming in to say that a REFS 3.4 volume cannot be seen by Windows 11 23H2.
refsutil reports no problem
Event Log says "The file system detected an allocation inconsistency on volume X:"
Apparently W11 / 26052 introduced ReFS V 3.14.
Agreed.
Understand this is a voluntary gist not related to official documentation, do you @0xbadfca11 to update this to reflect the changes happened post 3.9?
What should be the source of information (except the changing version numbers)? The official documentation hasn't seen update for more than a year.
Tbf, that page is open to contributions, but I'm imagining something like this gist would never be accepted.
So you are suggesting to make contributions to Microsoft documentation based on.. what? Some guesswork?
Is observed behavior guesswork?
Yes, as any empiricism.
I declare this article to be outdated.
I'm depressed and can't do activity right now. Also cannot promise
anything about future updates.
I declare this article to be outdated. I'm depressed and can't do activity right now. Also cannot promise anything about future updates.
Hope you will get better soon! Thanks the initial work!!!
I declare this article to be outdated. I'm depressed and can't do activity right now. Also cannot promise anything about future updates.
That is unfortunate to hear; I wish you the best. Thank you for your work, it is much appreciated.
Thank you for the notice and including it in the top. Also, massive thanks for all the time and maintenance of this gist!
Just for those that might overlook it, ReFS version to be continued here: https://gist.github.com/XenoPanther/15d8fad49fbd51c6bd946f2974084ef8
I found a new feature in ReFS v3.14 in build 24H2 release preview
I love how the official documentation removed the version info, and just links here instead
This gist is no longer updated can you cite the reference?
Thank you for spotting this @13xforever. Strongly believe this was an update request from my end longer ago.
MSFT docs never contained this specific versioning information focused on ReFS features and limitations only. My attempts to implement a similar thing as this gist (or maintained follow-up), were not successful.
I have filed a PR to address this: MicrosoftDocs/windowsserverdocs#7960
Much appreciate participation!
As per request of the original maintainer, let's continue on the gist linked above.
They had a table comparing ntfs/refs features with specific version notes when they were implemented
Ah yes. I can remember that. They used footnotes. But that was hard to read at times and not easy to maintain. Some changes that I proposed back then via PRs.
Since the most ReFS features are available on fully supported Windows Server / Client versions, I think the reference is a good approach.
After a Windows Update from Windows 10 22H2 to Windows 11 23H2 build 22631.2715, a ReFS volume (mirrored storage space) became inaccessible. The event log is full of entries like "Volume X: is formatted as ReFS but ReFS is unable to mount it; ReFS encountered status The file system encountered a metadata file with inconsistent data."
ReFS was version 3.4 when it was created six months ago. I do not know if it silently updated to a newer version after that. fsutil fsinfo refsinfo x: now gives "Error: The file system encountered a metadata file with inconsistent data. A local REFS volume is required for this operation."
It is obviously a disgrace that a simple Windows Update can (again) break ReFS. Perhaps the experts here have some suggestions?
I posted about this experience at https://techcommunity.microsoft.com/t5/windows-11/refs-volume-inaccessible-after-update-from-windows-10-22h2-to/m-p/3999414
Just wanted to post a warning to anyone else upgrading: I had almost the same experience, except that 23H2 started WRITING to the RAW volumes in the background (System process kept doing activity on the non-mounted RAW volumes). I thought, OK, weird, it should not be doing that if it does not know their filesystems.
To mitigate the problem and to understand if the Microsoft touted "ReFS improvements" do any good in W11 24H2, I updated to it and now the volumes got mounted and the directory data seemed fine. That is, until I clicked a file and was greeted by "file not found" error. Every existing file data "disappeared". The directory metadata is still there, I am still able to create new files and access them, but I can now only export old files using refsutil to access their data, I only see dead husks of the existing files everywhere.
I think W11 started upgrading ReFS volumes without notice and corrupted them in the process.
After a Windows Update from Windows 10 22H2 to Windows 11 23H2 build 22631.2715, a ReFS volume (mirrored storage space) became inaccessible. The event log is full of entries like "Volume X: is formatted as ReFS but ReFS is unable to mount it; ReFS encountered status The file system encountered a metadata file with inconsistent data."
ReFS was version 3.4 when it was created six months ago. I do not know if it silently updated to a newer version after that. fsutil fsinfo refsinfo x: now gives "Error: The file system encountered a metadata file with inconsistent data. A local REFS volume is required for this operation."
It is obviously a disgrace that a simple Windows Update can (again) break ReFS. Perhaps the experts here have some suggestions?
I posted about this experience at https://techcommunity.microsoft.com/t5/windows-11/refs-volume-inaccessible-after-update-from-windows-10-22h2-to/m-p/3999414Just wanted to post a warning to anyone else upgrading: I had almost the same experience, except that 23H2 started WRITING to the RAW volumes in the background (System process kept doing activity on the non-mounted RAW volumes). I thought, OK, weird, it should not be doing that if it does not know their filesystems.
To mitigate the problem and to understand if the Microsoft touted "ReFS improvements" do any good in W11 24H2, I updated to it and now the volumes got mounted and the directory data seemed fine. That is, until I clicked a file and was greeted by "file not found" error. Every existing file data "disappeared". The directory metadata is still there, I am still able to create new files and access them, but I can now only export old files using refsutil to access their data, I only see dead husks of the existing files everywhere.
I think W11 started upgrading ReFS volumes without notice and corrupted them in the process.
I've got multiple mirrored ReFS volumes working perfectly fine on 24H2. So it must be an issue with your configuration. Please don't try to stop file system access before making sure it's not a repair job. If you stop a repair, you can actually have data loss. A fact often unknown is that Windows clients sometimes don't run the scrub job in the Task Scheduler. Not running that for a long time can create incorrectable errors on ReFS volumes. I set mine to auto-run every now and then.
After a Windows Update from Windows 10 22H2 to Windows 11 23H2 build 22631.2715, a ReFS volume (mirrored storage space) became inaccessible. The event log is full of entries like "Volume X: is formatted as ReFS but ReFS is unable to mount it; ReFS encountered status The file system encountered a metadata file with inconsistent data."
ReFS was version 3.4 when it was created six months ago. I do not know if it silently updated to a newer version after that. fsutil fsinfo refsinfo x: now gives "Error: The file system encountered a metadata file with inconsistent data. A local REFS volume is required for this operation."
It is obviously a disgrace that a simple Windows Update can (again) break ReFS. Perhaps the experts here have some suggestions?
I posted about this experience at https://techcommunity.microsoft.com/t5/windows-11/refs-volume-inaccessible-after-update-from-windows-10-22h2-to/m-p/3999414Just wanted to post a warning to anyone else upgrading: I had almost the same experience, except that 23H2 started WRITING to the RAW volumes in the background (System process kept doing activity on the non-mounted RAW volumes). I thought, OK, weird, it should not be doing that if it does not know their filesystems.
To mitigate the problem and to understand if the Microsoft touted "ReFS improvements" do any good in W11 24H2, I updated to it and now the volumes got mounted and the directory data seemed fine. That is, until I clicked a file and was greeted by "file not found" error. Every existing file data "disappeared". The directory metadata is still there, I am still able to create new files and access them, but I can now only export old files using refsutil to access their data, I only see dead husks of the existing files everywhere.
I think W11 started upgrading ReFS volumes without notice and corrupted them in the process.I've got multiple mirrored ReFS volumes working perfectly fine on 24H2. So it must be an issue with your configuration. Please don't try to stop file system access before making sure it's not a repair job. If you stop a repair, you can actually have data loss. A fact often unknown is that Windows clients sometimes don't run the scrub job in the Task Scheduler. Not running that for a long time can create incorrectable errors on ReFS volumes. I set mine to auto-run every now and then.
I get what you mean, but the days of special configuration excuses are gone. These days every single machine is potentially a super special configuration. The problem is 23H2, I am 99% sure of it. None of the tools reported any errors before or after but 23H2 started writing to the RAW disk like crazy. Also, I got HDDs and SSDs. The process on the SSDs came to a halt I think, still same result.
After a Windows Update from Windows 10 22H2 to Windows 11 23H2 build 22631.2715, a ReFS volume (mirrored storage space) became inaccessible. The event log is full of entries like "Volume X: is formatted as ReFS but ReFS is unable to mount it; ReFS encountered status The file system encountered a metadata file with inconsistent data."
ReFS was version 3.4 when it was created six months ago. I do not know if it silently updated to a newer version after that. fsutil fsinfo refsinfo x: now gives "Error: The file system encountered a metadata file with inconsistent data. A local REFS volume is required for this operation."
It is obviously a disgrace that a simple Windows Update can (again) break ReFS. Perhaps the experts here have some suggestions?
I posted about this experience at https://techcommunity.microsoft.com/t5/windows-11/refs-volume-inaccessible-after-update-from-windows-10-22h2-to/m-p/3999414Just wanted to post a warning to anyone else upgrading: I had almost the same experience, except that 23H2 started WRITING to the RAW volumes in the background (System process kept doing activity on the non-mounted RAW volumes). I thought, OK, weird, it should not be doing that if it does not know their filesystems.
To mitigate the problem and to understand if the Microsoft touted "ReFS improvements" do any good in W11 24H2, I updated to it and now the volumes got mounted and the directory data seemed fine. That is, until I clicked a file and was greeted by "file not found" error. Every existing file data "disappeared". The directory metadata is still there, I am still able to create new files and access them, but I can now only export old files using refsutil to access their data, I only see dead husks of the existing files everywhere.
I think W11 started upgrading ReFS volumes without notice and corrupted them in the process.I've got multiple mirrored ReFS volumes working perfectly fine on 24H2. So it must be an issue with your configuration. Please don't try to stop file system access before making sure it's not a repair job. If you stop a repair, you can actually have data loss. A fact often unknown is that Windows clients sometimes don't run the scrub job in the Task Scheduler. Not running that for a long time can create incorrectable errors on ReFS volumes. I set mine to auto-run every now and then.
I get what you mean, but the days of special configuration excuses are gone. These days every single machine is potentially a super special configuration. The problem is 23H2, I am 99% sure of it. None of the tools reported any errors before or after but 23H2 started writing to the RAW disk like crazy. Also, I got HDDs and SSDs. The process on the SSDs came to a halt I think, still same result.
Try the Microsoft ReFS recovery tool then and copy everything to a new volume, maybe make a RAW backup first or get it to be read-only. That's all advice I can give.
I like to enable ReFS file integrity checks in an attempt to reduce the chance of unexpected corruption. Though there's hardly any official guidelines besides that they write that the feature exists.
That said, I did also upgrade to 23h2 and then to 24h2 and upgraded all my ReFS volumes without any issue.
When you in-place upgrade all ReFS volumes that are not set as "offline" will be upgraded to the latest ReFS unless you set the registry to block the upgrade.
The upgrade process will write on the disk for the ReFS metadata update.
There is no progress showing anywhere.
Mind that this gist is no longer updated. I would appreciate if discussion would be moved to
https://gist.github.com/XenoPanther/15d8fad49fbd51c6bd946f2974084ef8
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
BSoD caused by ReFS.sys when I connected my Windows 10 storage space (4 HDDs with ReFS format) to the SATA interfaces of my newly installed Windows 11 PC.
By then performing a clean install of Windows 10 on this PC with no hardware configuration changes, I have confirmed that this storage space can be mounted successfully.