I don't want to throw this thread into madness, but shouldn't we be careful before we immediately state that 64k is the only recommendation for ReFS?
The recommendation from Microsoft is still 4k for the majority of workloads: https://blogs.technet.microsoft.com/fil ... -and-ntfs/
Granted, they do state that, "64k clusters are applicable when working with large, sequential IO, but otherwise, 4K should be the default cluster size." Likely Veeam falls within that 64k recommendation, but why then was the initial recommendation from Veeam to utilize 4k unless the volume was large, 100TB I believe. IIRC, Gostev pointed that out in his video here: https://www.youtube.com/watch?v=V3vrsonuLE8&t=1841s
Due to the large IO size from Veeam we're sacrificing 5 - 10% of space for a problem that potentially could be resolved by sizing the repository server properly. As stated in this thread, 4Gb of memory per core is the recommendation wouldn't OP need 64 Gb just for the Veeam operations assuming he's at 16 threads and is hitting the recommendation of 1 core for every thread? We know that ReFS prioritizes data availability over everything else and it appears to do so via memory consumption. We might just need to take that into consideration when sizing repositories. https://technet.microsoft.com/en-us/lib ... 24(v=ws.11
. ReFS prioritizes the availability of data. Historically, file systems were often susceptible to data corruption that would require the system to be taken offline for repair. With ReFS, if corruption occurs, the repair process is both localized to the area of corruption and performed online, requiring no volume downtime. Although rare, if a volume does become corrupted or you choose not to use it with a mirror space or a parity space, ReFS implements salvage, a feature that removes the corrupt data from the namespace on a live volume and ensures that good data is not adversely affected by nonrepairable corrupt data. Because ReFS performs all repair operations online, it does not have an offline chkdsk command.Proactive Error Correction
. The integrity capabilities of ReFS are leveraged by a data integrity scanner, which is also known as a scrubber. The integrity scanner periodically scans the volume, identifying latent corruptions and proactively triggering a repair of that corrupt data.