I have a ZFS Proxmox installation and want to create a Fedora Server VM on it.
I read from somewhere that a CoW filesystem (e.g. QCOW2, ZFS, BTRFS) on top of ZFS is generally a bad idea (higher performance overhead, increased SSD wear, etc.).
Is XFS on Fedora Server CoW? I can’t find a definitive answer on the internet. Some source says COW is a optional feature on XFS, but I am not sure.
It is, in general, an overwriting file system.
But it does support reflinks, a.k.a. reflink copies, a.k.a. shared extents.
Reflinks: two or more files that share one or more extents. If you use cp --reflink-always to make a copy of a file, the file metadata is duplicated such that there are two completely independent and unique files (different inodes), but they both point to the same extents. It’s also OK to say the files are deduplicated, or snapshots.
If an application modifies a file such that a shared extent will be changed, the file system will COW that extent, in effect unsharing it. That way they can be unique (different).
If you have file A, and make copies B and C. Then modify C. The extent(s) for A are initially shared by all three files. The extent is duplicated via COW to a new empty location, for file C. So now A and B share the original extent. And C has an extent to itself containing some unique data representing the modification. Any subsequent writes to file C for this extent are not COW, they are overwrites.
XFS metadata isn’t COW, it’s always overwritten.
For most workloads I’d say it’s OK to consider it not as a COW file system, even if you use reflink copies. If the workload involves many reflink copies of very large files like VM images or large databases, then it might be a factor and you’d just need to test it - but I’m pretty sure since the metadata is overwriting, you don’t need to consider it a COW file system for the purpose under discussion.
Great answer, but if I may try to clarify,
When a file-system allows shared data, then modifying a shared block requires something like CoW to preserve the original block for the other sharers. The a file component (like a data block) is NOT shared then the FS may either modify that same block OR it can allocate and create a new block that merges the write/changes and then update that metadata.
btrfs (unless mounted nocow) always allocates new storage for all modify/writes, even on not-shared blocks.
xfs, by default, does a modify-in-place unless the block is shared; then it does a CoW.
bcachefs, like btrfs does a CoW type operation even on not-shared blocks, although it also has superblock ‘nocow_enabled’ options that can make modify in-place for not-shared blocks.
Neither the btrfs nor bcachefs ‘nocow’ fs option prevents these from creating reflink (clone) files on copy.
It seems that the CoW for unshared blocks causes considerable extra writes, but it is claimed that this method, if sequenced properly, keeps the on-disk filesystem in a more recoverable state.