Correct, I have ran into the very person who has added this comment to the article, and he gave me his reasoning behind one. This was during Q&A after S2D/ReFS breakout session he presented, so there were a few other attendees participating in the discussion as well.
Hannes - Microsoft is a big company and I think we're in wrong position to clear out the confusion between their multiple departments
for me, the answer I've got is good enough - even if I personally would put this note in a different manner now that I know what issue it is talking about.
Anyway, the main point of my post was that the technical issue that this statement is supposed to address is NOT specific to ReFS. And what I really wanted everyone to take away from my post was that any backup storage which controller that does not process the flush command correctly is not supported by Veeam regardless of the file system used
.This has always been the case, so not something new. And yes Johnny, it most certainly applies to RAID controllers in regular servers as well, because nothing prevents them from potentially implementing ATA specification incorrectly. Limiting the problem to SAN-attached storage and ReFS as the note does is the classic case of survivor's bias.
The good news is that as I noted, in our experience the issue seems to be somewhat isolated to low-end consumer-grade storage hardware, and in general is not that common. To explain the actual issue in a bit more details: a part of ATA specification is the flush command that must cause the storage controller to write all data from its write cache to disk media disk before returning success. But some storage controllers will return success immediately upon receiving the flush command, without actually flushing the buffers to disk (or without waiting for the flushing to complete). This can happen either due to a firmware bug, or simply to make the storage perform better in performance tests. This behavior may cause data corruption in situations such as sudden power loss, because the application or file system thinks that the data has landed on media when it actually did not. Flush is absolutely critical for transactional workloads because this is how storage transactions actually get finalized - and most applications may experience data corruption or data loss issues when backed by such storage. Even Notepad and Paint can be impacted - as after clicking Save the data will still remain in cache, and the following unexpected computer shutdown will cause that data to be lost.
By the way, if you ever wondered why Microsoft does not support Storage Spaces in a VM
for example, which also works perfectly fine, then the reason is the same. They want direct access to the actual hard drives and nothing else in the I/O path, not to have to deal with potential bugs of those additional "storage layers that abstract the physical disks". Otherwise, they'd have to test and certify every existing version of every possible layer, which is not doable.