Are BtrFS snapshots killing my SSD?

Question

As I know, BtrFS snapshots don't actually copy data. I suppose, actual copying executes on every change of snapshoted data.

So is it right that BtrFS partition on SSD with enabled Snapshots doubles the wear of SSD memory? One write for new data and second write for recording diff to snapshot.

I already use BtrFS with Snapshots as filesystem for / partititon for a considerable time and several times it really helped me. But now I going to install system on SSD.

Answer 1

TL;DR

No, it won't reduce the lifetime of your SSD any more than using BTRFS without snapshots will.

Explanation

There are a couple of different ways to implement snapshots in software:

1. You store an exact copy of all the data being snapshotted. This isn't very efficient (both in terms of space and time), but is the only option that stores a true historical copy of the data and is pretty trivial to implement. Because of the efficiency issues, it's not widely used for snapshots, but this is in essence what a full backup of a volume does.

2. You store a copy of the differences between the current state and the historical states of the data. This method has performance issues when reading data because the system has to compute the state of the requested data at the requested time. This can be layered one of two ways:

   a. Each snapshot stores the differences between the current state of the data and the state of the data when the snapshot was taken. This is space efficient, but not time efficient (since the time to write out a change scales linearly with the number of snapshots). Read performance is poor for snapshots, but decent for the current data. This method isn't widely used because it's somewhat tricky to implement, and write performance is so bad that you might as well just store a full copy.

   b. The first snapshot taken archives the state of the data at that moment, and subsequent snapshots store only the differences since that copy, with the current state being a special case that changes as the user updates it. This is only space efficient if you're only modifying existing data and not adding or removing any data, but is more time efficient than 2a. Read performance is poor for most snapshots and the current data, but fine for the first snapshot. This is how incremental backups work, and in a special arrangement where each diff is against the previous version is what version control software does, but it isn't very widely used for snapshots because the next option is better in almost every way.

3. Snapshots are implemented via copy-on-write (COW) semantics. This is the most space efficient option, and is on average more time efficient than both variants of method 2. With COW snapshots, any given piece of data is stored once, and each snapshot that includes that data references it. This solves most of the issues with options 1 and 2. There are two ways to handle COW snapshots too:

   a. When a given piece of data changes in the current version, copy the old data to the snapshot, and then update the new data. This causes the first write to a location after taking a snapshot to have performance issues, but subsequent writes to be fine and performance is otherwise reasonable. This is how LVM implements snapshots, because it's very easy totack on to an existing data set that wasn't already using COW semantics.

   b. When a given piece of data changes in the current version, create a new copy of that location in the current version and store the changed data there. This avoids the first-write performance issues with option 3a, but incurs a performance penalty when deleting snapshots (because you have to validate references on every bit of data to figure out whether you can delete it or not). This is how ZFS and BTRFS implement snapshots (though BTRFS uses method 3a in certain very specific circumstances).

Because BTRFS uses method 3b, the only increase in overhead from using snapshots in in the handling of metadata, which should account for a miniscule percentage of the actual data written by BTRFS (and the metadata updates happen anyway, they're just marginally smaller without snapshots).