I think more people should know about #reflinks, which I learned about from @leah years ago.

(100% human-written prose. I use em dashes and bulleted lists because they make the prose clearer. Also, I like them.)

Immutable copy-on-write snapshots of things are kind of a superpower for computer systems design. (FP folks call this "persistence.") An awfully large fraction of computers' time is spent copying things from one place to another to keep them from changing. In a lot of cases, this is unnecessary, because they weren't actually going to change in the first place, but it can be hard to be sure in advance. If you have some kind of system that will copy *only* the things that get modified — or the *parts* of those things that get modified — it will often be much more efficient. So, in Linux, we use this a lot in copy-on-write memory mappings of files, process memory following a fork(), and things like that. rsync has a --link-dest option that allows multiple backups to share space while being just as convenient to use as regular non-incremental backups. There are many other examples.

Some OSes and some filesystems support making a copy-on-write "copy" of a file, sharing the space between the original file and the "copy" until and unless one of them change. This feature is usually called "reflinks" after the Solaris system call that supports it.

In particular:

On #Linux:
- Bcachefs,
- btrfs,
- XFS, and
- OCFS2.

But *not* OpenZFS.

On #FreeBSD, neither OpenZFS nor #ZFS.

On Solaris, ZFS (with `cp -z`).

On MacOS, APFS (which Apple is switching to; with `cp -c` or the `clonefile` system call)

And, on Microsoft Windows, NTFS and its DUPLICATE_EXTENTS_TO_FILE.

These are from Daniel Aleksandersen's 02020 blog post https://www.ctrl.blog/entry/file-cloning/. I don't think anything has changed on that front since then, which is sad, if true.