Storage is one of those parts of Linux that most people only think about when something breaks. You pick a file system during install, trust it with your files, and then forget it exists. It sits under everything: your OS, your home folder, your logs, your downloads, your work, and all the small mistakes you make while changing things. For years, that mostly means one thing: when a file changes, the old data is overwritten by the new data, and you move on.
Copy-on-write (CoW) changes that bargain in a way that almost feels like cheating. Instead of rushing to overwrite old blocks, a CoW file system writes the changed data somewhere else and then updates its map. That simple shift is what makes snapshots, cheap clones, rollbacks, and smarter backups possible.
CoW changes the rule you thought was fixed
New writes leave old blocks alone
On a plain file system, changing a file often means changing the old blocks in place. On a CoW file system, the old blocks are left alone, and the changed data is written to new blocks. Only after that does the file system update its pointers.
This means the file system can keep an old view of the data without making a full second copy at the start. That one idea sits behind most of the features that make CoW feel unfair the first time it saves you. A snapshot can hold the old state. A cloned file can share blocks with the first file. A backup stream can send only what changed after an earlier snapshot.
Changed data still takes space. If you keep months of snapshots while rewriting huge files every day, your disk will still fill up and then look at you like you deserve it. The real deal is not that storage becomes free but how unchanged data does not need to be copied again just so you can keep another view of it.
The easiest way to feel CoW working is to think about a large file, such as a VM disk image. If you copy it the normal way, you get another full copy. If you copy it with reflinks on Btrfs, the second file starts out by sharing the same data blocks as the first. Both files look real, can be opened and changed. Yet the second one does not need another full pile of space at once.
When one copy changes, only the changed parts need new blocks. The unchanged parts remain shared. This is the reason snapshots are so useful. A snapshot of a subvolume can be made almost at once, because it begins as another view of the same blocks. As the live system changes, the snapshot keeps holding the old blocks. That makes snapshots perfect before system upgrades, risky config edits, package cleanups, and late-night experiments that begin with “this should only take a minute.”
Btrfs Is the Linux friendly way in
It is close to the kernel and easy to reach
On Linux, Btrfs is the easiest way to start using CoW storage. It lives in the kernel tree, its user-space tools are widely packaged, and many distributions know how to install directly onto it. Debian can use Btrfs during installation, and on a spare disk you can start testing it with only a few commands.
Btrfs gives you subvolumes, snapshots, checksums, reflinks, and send/receive. This makes it useful on laptops, desktops, small home servers, backup drives, and test boxes. You can keep your root file system on one subvolume, your home directory on another, and your snapshots somewhere easy to manage.
OpenZFS is the other big name in this space, and there are cases where it is the better choice. If you are building a storage server with mirrors, RAIDZ, datasets, quotas, scrubs, snapshots, and replication, OpenZFS often feels more mature. Its tools are clear, its pool model is strong, and its history in storage-heavy setups is hard to wave away.
Backing up isn’t enough: A modern guide to ZFS on Linux
It’s awesome—but it, sadly, has some downfalls.
The catch is Linux support, OpenZFS on Linux has improved a lot, and recent releases keep up with newer kernels better than it once did. Still, it is not as close to Linux as Btrfs. Btrfs is part of the kernel whereas OpenZFS is not, mostly because of licensing, so on Debian it comes through contrib and DKMS packages that build a kernel module for your system. This works well for many users, but it remains another moving part.
Set up a safe btrfs setup on Debian
Use a loopback disk before touching real data
The best way to learn about CoW is not to reinstall your machine. Use a spare disk, a USB SSD, or a loopback file. A loopback file is slower than a real disk, but it is good enough for learning snapshots, reflinks, and subvolumes without risking anything useful.
Install the tools first:
sudo apt update -y
sudo apt install btrfs-progs -y
Create a test image:
truncate -s 5G ~/btrfs-demo.img
sudo losetup --find --show ~/btrfs-demo.img
The last command prints a loop device, such as /dev/loop11. Using the device, the system shows:
sudo mkfs.btrfs -L cowdemo /dev/loop11
sudo mkdir -p /mnt/cowdemo
Create a subvolume and clone a File
This is where CoW starts to look fake
Create a subvolume for your test data:
sudo btrfs subvolume create /mnt/cowdemo/@data
sudo mkdir -p /mnt/cowdemo/@data/projects
A subvolume looks like a folder, but Btrfs treats it as its own file tree. That is why it can be snapshotted on its own.
Now create a large test file:
cd /mnt/cowdemo/@data/projects
sudo dd if=/dev/zero of=bigfile.img bs=1M count=1024 status=progress
Make a reflink copy:
sudo cp --reflink=always bigfile.img bigfile-copy.img
ls -lh
sudo btrfs filesystem du -s .
ls shows two large files, but Btrfs knows they share blocks. You appear to have copied a 1GB file, yet the file system has not spent another full gigabyte right away.
Now change part of the copy:
sudo dd if=/dev/urandom of=bigfile-copy.img bs=1M count=50 conv=notrunc,fsync status=progress
sync
sudo btrfs filesystem du -s .
Only around 50 MiB became new unique data, while most of the 1 GiB is still shared. The shell says there are two 1 GiB files but Btrfs says only 1 GiB is actually shared on disk, and that is the part that really does feel like cheating.
3 copies, 2 formats, 1 big problem: Why modern backups fail
The ‘3-2-1’ backup rule is finally outdated – here’s what to do instead
CoW changes how you think about storage
CoW is easy to undersell if you describe it as one more file system feature, because the real change is in the habits it makes possible. Instead of copying a whole directory before testing a risky change, you can take a snapshot, use old states, cheap clones, and rollback paths, and keep working. Once that clicks, CoW feels like one of those Linux features you wish you had learned years ago.



