I'm using FreeBSD 11.1 and the output of zfs list -t snap -r poolname
shows a large number of my snapshots with "0" under "USED". I've read up on how ZFS accounts for space so I understand the basics, and they suggest to me that
- "0" means the snapshot uses no disk space, in the sense that deleting it recovers no disk space.
- If a file is present in 2 snapshots, this wont improve redundancy on that file because all it means is multiple pointers (references) to that file exist (or more exactly, to the series of blocks making up that file), not that extra copies exist.
So logic suggests that any snapshot with USED=0 is likely to be an identical copy of the previous snapshot of rhat object, and safe to delete if you don't want to keep snapshots for which nothing changed from the previous snapshot, and no redundancy is lost by doing so.
I'm very attached to not deleting old data or reducing redundancy if it reduces data safety, and I can think of at least a couple of possible reasons it might not be all that simple:
Snapshot USED values can change when other snapshots are destroyed, but equally the presence of zero size should strongly suggest in almost any normal usage, that another snap exists of non-zero size that it's identical to. But "strongly suggests" doesn't mean "implausible that it's not so", and zero means all blocks exist not that they are identically organised and the files are the same. Are there any cases where it's not necessarily safe to "out of hand" delete all zero-size snaps?
As an example of this, imagine we (1) create a 100MB file and snapshot the pool, then (2) create two other 75MB files containing the first and last 75% of the 100MB file respectively, and delete the 100MB file, then snapshot again. The second snapshot will show 0 space used because all blocks exist in the previous snap, but the files in that snapshot are in fact unique. I can't think of a way to detect this because space accounting in ZFS is block not file based. Perhaps with dedup in use and some types of file that get appended or 'tail'ed this might be common if rare, not just a pathological edge case.
So I'm unsure. Perhaps snap size is a red herring and I need to check other properties instead.
Are there any non-trivial circumstances one can safely and quickly determine whether a ZFS snapshot is redundant (in the sense I'm using the term), and that its safe to delete it?
Or is there another better (quick+effective) way to tell, from other properties or ZFS diffing or whatever, whether two sequential snaps actually point to the same point in time/pool write sequence number in the pool's history (which would categorically confirm they reference identical data)?