We're seeing major issues in this regard also. We were having out-of-memory issues where the system (multiple 2016 servers) would go into a non-responsive state and have to be hard-powered off. In particular, the memory would balloon up to 100% and kill the system when the "Microsoft->Windows->Data Integrity->Data Integrity Scan for Crash Recovery" task in task scheduler would auto-trigger following an unclean shutdown.
The latest round of MS updates seems to have updated the ReFS driver version and we haven't had it crash again when going through a scrub, but we *are* seeing very bizarre memory issues. For example... I just deleted ~10TB of old Veeam backup data. Memory utilization (out of 32GB) climbed from practically nothing being used to 98% of memory being used. Free space (as explorer reports) slowly, slowly climbed over an hour or two. The disks were staying busy the entire time as well. After that finished, and the free space all showed up and the disks went idle, memory continued to remain at 76% utilized, and when I check sysinternal's RAMMAP, it reports 21GB of "active" Metafile allocation. IE: ReFS. I also confirmed this with poolmon and tracking down the driver tags.
It's possible that this memory will be yielded when something else needs it, but in that case it should be reported as "Standby" in RAMMAP or "Cached" in Task Manager.
We also had unrepairable integrity failures in our Veeam backup chain after extending Storage Spaces and the underlying filesystem following addition of new disks. It's a mirrored arrangement. None of the disks are reporting errors. The odds that there were unreported disk errors in the same location on two separate disks is infinitesimal.
On a *separate* 2016 system than the one that reported integrity errors following its expansion, we ran into a bug in which the ReFS filesystem was expanded, but explorer couldn't see the additional space. Adding more disks and expanding further didn't fix the problem. And ReFS, unlike NTFS, doesn't support shrinking. We had to create a separate vdisk, sync non-veeam data (because the veeam data is block-aligned on refs), destroy the "bad" vdisk, create a new one, confirm it expands successfully, sync data back, and re-copy veeam data from the primary backup server.
In short... ReFS + Storage Spaces is a hot mess. It has some advantages, and I'm not saying people shouldn't use it - but be very cautious. None of this is Veeam's fault, but be aware that even today, years after it was released for the first time, this is still very much alpha/beta-quality stuff from Microsoft. I remember when Storage Spaces was first launched - it would literally *crash* when a filesystem reached 100% disk utilization and would be unmountable to even resolve the problem.
I'm not sure how much any of these issues relate to the block clone API, which is quite new, or are just general ReFS+Storage Spaces issues, but... everyone needs to be careful here. When you are adding disks and extending Storage Spaces filesystems, do it *one server at a time* and then run a full Data Integrity scrub (see above Task Manager path) and wait the day(s) it takes for it to finish before moving on to the next server. That way, if you need to do something crazy like nuke a vdisk to fix a MS glitch, you won't find (like I did), that you suddenly have bizarre integrity failures in the Veeam backups on your *main* backup repository. In the end, I got everything fixed and new backup chains repopulated, but it was nerve-wracking there for a few hours.
Also - if anyone else has the unclean-shutdown-scrub-of-death thing going on like I did ... I didn't know about the task at the time. If stopping it works, great. Do that quickly before it kills the system, and then run updates to get the latest version of the ReFS driver that seems to fix that. If you can't stop the process, you can do what I did - kill the system (it won't shut down properly), and then pull every disk from the server except the OS disk. Then, run updates, shut down, and reinsert the disks.