That'd be great, if I didn't have to turn it off. System Restore is so slow as to be borderline unusable. (In my experience creating the restore point accounts for the majority of time Windows spends doing updates, on a true CoW filesystem this should be nearly instantaneous.) Furthermore if you have VSS enabled on a volume hosting an MSSQL database it creates entries in the backup log for every snapshot, which destroys the chain of differential backups. This makes it impossible to use SQL Server Agent's maintenance plans alongside VSS in small-scale deployments (e.g: a workstation.)
I cannot stress enough: NTFS is not a CoW filesystem, any attempt to add CoW features on top of it will be poorly performant and doomed to fail, because they actually have to copy the old data blocks when you overwrite something. ZFS, btrfs, et al. are not actually copying user-data, because they don't have a concept of "ovewriting a block," every block that is written is written to unallocated regions of the disk; blocks that are not referenced by a dataset or snapshot are then returned to the allocator for later use; at no point is the old data "copied", it's just "not returned to the allocator for reuse."
What btrfs or ZFS mean by "copying" is not the user's data blocks, it's copying filesystem metadata, portions of btrfs' extent tree, or ZFS' block pointer tree. There is a world of difference between volume shadow copy, and an actual CoW filesystem. -- Microsoft knows this, that's why they are working on ReFS. (Of course in typical MSFT fashion they've made a number of critical mistakes: user data checksums are optional, and volume management is not integrated so it can't even use those integrity streams to self-heal corruption. Also last I checked ReFS can't even be used as a bootable Windows volume. -- It's worth pointing out APFS also made the mistake of checksumming metadata but not user data; which in my opinion makes both of them unsuitable as next generation filesystems.)
> ZFS, btrfs, et al. are not actually copying user-data, because they don't have a concept of "ovewriting a block," every block that is written is written to unallocated regions of the disk
Unless you just so happen to be writing over an entire block, then there still must be a copy happening. The old data, less the bytes you modified, must be written into the new block along with your changed bytes.
AFAIK no disk hardware (or filesystem) supports _actual_ byte writes, and never has. They all work by reading in a block (say 512 bytes minimum), changing the bits you asked it to and writing the new block out. So it's no extra effort to simply write the new block to a different location.
