4

Short Version

I have files on a ReFS volume where Integrity Stream integrity is Enforced is true.

PS M:\> Get-Item Contoso.vhdx | Get-FileIntegrity

FileName         Enabled  Enforced
--------         -------  --------
M:\Contoso.vhdx  False    True

I want to turn Enforced off:

PS M:\> Get-Item "M:\Contoso.vhdx" | Set-FileIntegrity -Enforce $False
PS M:\> Get-Item Contoso.vhdx | Get-FileIntegrity

FileName         Enabled  Enforced
--------         -------  --------
M:\Contoso.vhdx  False    True

How do i turn off Enforced file integrity?

Long Version

ReFS has a feature known as Integrity Streams. When you enable this optional feature for files, the filesystem maintains a CRC of the file. With this checksum, it can validate that a file has not been damaged.

The down-side of the Integrity Streams feature is:

  • if it detects even a single-bit error
  • in an otherwise fine 340 GB file (e.g. ProductionServer.vhdx)
  • it will delete the entire file

No warning. No question. No appeal. One uncorrectable bit and you lose all your data.

This is what Enforced means. It means that you are forced to suffer complete data loss. And if you didn't like it: you shouldn't have enabled file integrity.

This behavior is quietly documented:

Key Benefits

Resiliency

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. ReFS keeps the volume online while it handles most non-correctable corruptions, but there are rare cases that require ReFS to take the volume offline.

(emphasis mine)

It's also partially documented in Set-FileIntegrity cmdlet:

-Enforce: Indicates whether to enable blocking access to a file if integrity streams indicate data corruption.

That sounds like the thing that we'd want to not exist. That sounds like the feature that no sane person on the planet would ever want to even exist, let alone have Enabled. And yet it defaults to on.

Note: It says "block", and the first page says "remove". Whatever the terminology: there is no way to access the file ever again. I.e. there is no way to "un-block" it, nor is there any way to "un-remove" it. In all ways that matter your data is gone.

How to turn off Enforced?

The question becomes: how do you turn it off?

You try running the powershell commandlet:

PS M:\> Get-Item "M:\Contoso.vhdx" | Set-FileIntegrity -Enforce $False

And it doesn't work. No error; it just doesn't turn the option off.

How to make it work?

  • Yes, running as an administrator.
  • Yes, on an elevated powershell.
  • Windows Server 2012 (6.2.9200)
  • Windows 10 (10.0.17763.864)

tl;dr: How to turn off Enforced file integrity on ReFS?

Enforced has no meaning until file integrity is enabled

I discovered in the intervening months even though file integrity might be Enforced, that enforcement doesn't have any effect until file integrity is Enabled.

If Enabled is $False, then the value of irrelevant.

File-Integrity

| Enabled | Enforced | Result    |
|---------|----------|-----------|
| $False  | n/a      | No effect | (Default) Irreparable damage will **not** cause the file to be deleted
| $True   | $False   | Good      | A good choice that you have to opt-into. File damage will be found, and simply reported in the event log
| $True   | $True    | Disaster  | Any damage that cannot be repaired and your file will be deleted without warning

I don't know why anyone would choose to enforce catastrophic data loss; but there the option is.

More information about the intentionlly deleting your data feature

I found a well hidden Word document by Microsoft. Application Compatibility with ReFS.docx:

Application Compatibility with ReFS

Microsoft Corporation
Published: March 2012

It mentions the feature (paradoxically termed "Salvage"), that instantly deletes your data:

1.7 Salvage

To maximize the availability of data on a volume, ReFS implements “salvage”, a feature that will remove corrupt data from the namespace in the event that the corruption cannot be automatically repaired. The intention behind this feature is to ensure that non-repairable corruption does not adversely affect the availability of non-corrupt data. If, for example, a single file in a directory were to become corrupt and could not be automatically repaired, salvage will remove that file from the file system namespace. A corrupt file cannot be opened or deleted by the file system, making it impossible for an Administrator to respond. With salvage, an Administrator can recover that file from a backup or have the application re-create it. Salvage is compatible with user files, directories, and other file system metadata.

For file system filter drivers, you must implement code that can gracefully react to a file or directory disappearing suddenly.

Note that ReFS does not require chkdsk and chkdsk will never run on a ReFS volume.

The rational for deleting files is...tautological:

this feature is to ensure that non-repairable corruption does not adversely affect the availability of non-corrupt data.

That doesn't make any sense, either in programming, logic, or english. But there it is.

3
  • It gets even better: ReFS can erase your data even if it is NOT corrupt on disk. All it takes is a bad read, bad cable, memory corruption, checksum calc error, etc - things that can easily cause a double checksum failure. I need to move to Btrfs or Zfs before ReFS "salvages" all my data.
    – Robot
    Commented Jan 22, 2020 at 5:11
  • When Enabled is true and Enforced is False and a checksum mismatch happens, is it only logged to Event Log or does the application receive an error? Commented Jun 10, 2020 at 18:11
  • ReFS does not delete anything! It's a misunderstanding. "...remove that file from the file system namespace" is not same as "deleting the file". Maybe it's not described what it means, but not deletion. Software has no access to the file and don't have to read it until to the error bit. This will be an unnecessary read and "removing from namespace" will avoid this read. But the file will still exist and is not deleted! If you disable the crc you will have access again. I testet this myself a few times with hex edited files, ReFS had never deleted anything.
    – Stoffi
    Commented Apr 12, 2022 at 1:46

2 Answers 2

5

I just want to note that I tested this behavior on the latest Windows 11, and here are my observations:

  1. If you have mirrored storage spaces, and data corruption in a file on a single disk, REFS will fix it automatically for you with integrity streams enabled
  2. If the corruption is on both disks, REFS will block access to the file, but it will not delete it. You can regain access to the file by manually changing the enforce flag to false (e.g. Get-Item 'E:\claclaboth.txt' | Set-FileIntegrity -Enable $True -Enforce $False)

Based on the findings above, I think you can leave the enforced flag default, as REFS will not delete your file, just block it, at least on Windows 11 and text files (which I used for the testing)

1
  • Win10,SRV2019: If you have a single disk with no redundancy it will also block the access to the file. Setting crc or the enforce parameter off will make the file accessible. ReFS does not delete anything!
    – Stoffi
    Commented Apr 12, 2022 at 1:34
0
Set-FileIntegrity -FileName 'M:\Contoso.vhdx' -Enforce $False

Removal of corrupt data from the namespace instead of flagging in place was a horrible design decision. The #1 reason to never use ReFS. The one and only reason I don't use ReFS.

As always, we can never have nice things. Never.

5
  • It turns out you can only turn off Enforce if you first turn on Integrity. You cannot turn off integrity while Enabled is $False. Which is somewhat terrifying: i want to make sure i am as far away from disaster as possible, so i want to make sure Enforced is False. But the only way to do that is to turn Enabled on. I don't want that! I want to see both $False and $False. I want to be as far away from danger as possible!
    – Ian Boyd
    Commented Jan 3, 2020 at 20:43
  • Integrity enforcement depends on integrity being enabled. By enabling integrity, ReFS maintains hashes for each file (on read, write, scrub) so it knows if a file is corrupt. Without enforcement (as your table show) it logs errors, and will only fix (single failure) or delete (double failure) files when enforcement is active.
    – Robot
    Commented Jan 3, 2020 at 23:50
  • 1
    The strategy is to enable file integrity checking but disable enforcement...until they have a reasonable repair algorithm. When I used ReFS I got many double failures, which is odd, because they never occur on Ntfs where I scan manually, so something about ReFS seems to induce un-repairable corruption, and then delete those un-repairable files. Its a double whammy. Always keep an up to date non-ReFS backup that you can recover from.
    – Robot
    Commented Jan 3, 2020 at 23:51
  • 1
    @Robot It is only an issue you will encounter if the following instances are all met: 1) You are running ReFS on a single drive, and a file is corrupted (in which case ReFS will return the 'bad' data if Enforced is False - but there is no possible way for ReFS to recover the error) 2) You are running ReFS on multiple drives, and all copies of the file are corrupted (in which case, this error can occur). Given that ZFS has precisely the same limitations (it makes things worse when run on a single disk, and prevents you accessing data at all when all copies are bad), where's the issue?
    – Minkus
    Commented Mar 7, 2022 at 22:17
  • 'Single disk ZFS is worse than no ZFS at all': truenas.com/community/threads/single-drive-zfs.35515 'The system knows the file is corrupt and thus the contents are not usable, but it has no way to fix it because both copies are damaged with no means of correction... The correct answer to what to do is what ZFS does - (blocks access to the file with a Permanent Error)' muc.lists.freebsd.fs.narkive.com/TuQkCunv/…
    – Minkus
    Commented Mar 7, 2022 at 22:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .