Clarification needed: Does ReFS still permanently delete files if even 1 bit of data becomes corrupt?

[GordonRudman]

I'm referring to this paragraph:
"Salvaging data - If a volume becomes corrupted and an alternate copy of the corrupted data doesn't exist, ReFS removes the corrupt data from the namespace"

With Integrity-streams enabled, is there any way to recover that data?
How would I be able to do that exactly?
This seems to be an unanswered question floating about the internet, so please can you clearly spell out exactly what will happen in this situation. If ReFS just deletes the file, and there is no way to recover it, then please put a big red bold warning sign around this paragraph.

I want to use ReFS with Integrity-streams on a dual Parity Storage Space, which seems like a good fit to me, but I don't want to put my data at risk. In the event of data corruption I would like to at least be able to get back the uncorrupted data from the same file.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 1239e469-71b9-faa2-9e4c-2999bbb06e87
• Version Independent ID: 5461ce26-c20b-4a04-692f-1a3721bb96f5
• Content: Resilient File System (ReFS) overview
• Content Source: WindowsServerDocs/storage/refs/refs-overview.md
• Product: windows-server
• Technology: storage-file-systems
• GitHub Login: @gawatu
• Microsoft Alias: gawatu

[likeman9]

@GordonRudman

you need to turn Enforced to False,, problem is there is zero way to make it permanent for New generated files as it refuses to inherit it from the folder path making New files or even just making a copy of the file is vulnerable to silent delete (once set to False on existing files it stays)

unless you run a command below every 15-60 minutes or a day that sets it to False (like task scheduler) R is the ReFs drive so change it to whatever your drive is (if the drive has lots of files you might want to run this at like 3AM as i made 2 folders with 50,000 of 100KB files and it takes 2-3 minutes to run using 80% of total cpu on 8 cores to process

Get-ChildItem -Recurse R:* | Set-FileIntegrity -Enable $True -Enforce $False -ThrottleLimit 1

the -ThrottleLimit 1 is there to make sure it does not consume all the CPU up of the total CPU (as on my virtualbox its using 3 threads it uses 6 when its on Threadlimit 2 so i would not use any higher then 1 unless you want to affect your server performance ), once the command has set all files to False any future runs of the command don't touch the disk if they are already set to False

and use
Get-Item -Path R:* | Get-FileIntegrity
to verify (only shows current path no sub folders)

with ReFs only use 2-3 way mirror and have a backup and don't use Parity (think of ReFs is like the early days of using RAID5/6 BTRFS on linux, the fix for that was to use Metadata as raid1 or raid1c3 and data for raid5 or raid6, random hoseing of the file system on ReFs can randomly happen making the drive become inaccessible is still a problem)

the Default current implementation is broken in ReFs as True should just return CRC error to the user and log it in the event log (not hide the file in hope that no one notices ReFs failed to use Parity or mirror to repair it) as who ever programed ReFs.sys thought it was a good idea to just silently hide the file and the worst is the file is removed from the namespace it isn't actually deleted so free space is not freed and impossible to free up up because you can't access the filename to delete it and you can't recover it because it will abort the MS recovery tool soon as it hits the part of the file that cannot be repaired so your only option is to delete the pool and recreate it if Enforced is set to True

but microsoft doesn't seem to be to interested in pushing to get this fixed as this "by design" bug has been not corrected for 2-3 years , silent deletion of data is a no (the error should be on access to the file that's all) with ZFS and BTRFS you just do whatever you want to do with the file to recover remaining data and then delete it

[mjohnsonn]

We are approaching two years since the last post here. What is going on with this issue? Isn't Microsoft worried about who is using ReFS and for what? What disaster will have to happen before this problem is addressed. If you use ReFS, you can easily lose all your data via a mechanism that has been fully known about for years.