ReFS integrity streams on Windows 11: confirming retried writes stay logically single

Answer – does ReFS retry a failed write?

ReFS itself does not perform write retries. When a write to an integrity‑stream file fails, the error is first seen by the underlying storage driver (disk.sys/storport.sys). If the driver classifies the error as transient (e.g., a temporary bus reset or a recoverable media error) it will issue its own hardware retry before returning a status to the file system. From ReFS’s point of view the write is a single logical operation that either succeeds after the driver’s internal retries or fails with a final error code.

Confirmed facts

• ReFS integrity streams use allocate‑on‑write (copy‑on‑write) for data and metadata, so a failed write never overwrites good data; the original block remains intact.
• The file‑open flags FILE_FLAG_WRITE_THROUGH and FILE_FLAG_NO_BUFFERING only affect when the data is flushed to the storage stack; they do not change the driver’s retry logic.
• From user mode a retried write appears as one logical WriteFile call that either returns success after the driver’s internal retries or returns a final error (e.g., STATUS_DEVICE_NOT_READY) after all retries are exhausted.

Steps to verify that no duplicate logical writes occur

1. Enable ETW tracing for the storage port provider to see driver‑level retry attempts:

logman start StorPortTrace -p Microsoft-Windows-StorPort -ets
# Run your test workload
logman stop StorPortTrace -ets

1. Open the resulting .etl file in Windows Performance Analyzer (WPA) and add the "StorPort\Retry" event (if present) or examine the "Disk I/O" graph for a single I/O with elevated latency that corresponds to a hardware retry.

1. From the application side, capture the return value of WriteFile/GetOverlappedResult. If you see a single success or a single error code, no duplicate logical write was visible to the process.

Missing diagnostic detail that would change the recommendation

If you observe a specific error code (e.g., STATUS_IO_TIMEOUT) that the storage driver treats as non‑retryable, the behavior could differ. Knowing the exact status returned by the driver would let you determine whether a retry is attempted or the error is propagated immediately.

Assumptions and uncertainty

• The answer assumes a typical SATA/NVMe stack where transient errors are retried by the firmware or driver. Behavior may differ with specialized hardware that disables retries.

• Integrity streams do not add any extra retry logic; they only provide checksum verification on read.