[solarengineer]

"It is important to regularly monitor the snapshot’s storage usage. If a snapshot reaches 100% of its allocated space, it will become invalid." [1]

ZFS snapshots use Copy-on-Write differently and have no such allocated space limit. Thus, we can do interesting things like snapshotting a file system after an OS is installed, and then roll back to that snapshot upon an OS upgrade failure, or even clone a new file system from that snapshot to have a different copy of the OS.

Essentially, the nature of the snapshots are different in both.

[1] https://docs.redhat.com/en/documentation/red_hat_enterprise_...

[tomega2134]

Snapshotting before OS upgrade is something that has saved my system more than once. It's not to be underestimated how much time is saved over having to restore from backup or reinstall.

Plus there is sending/receiving snapshots across systems if you want to.

[regexorcist]

You can do those things with LVM snapshots too, that's what they are used for.

[solarengineer]

When we allocate space to an LVM snapshot, the COW data is written to that space and then when that space is used up the LVM snapshot must either be given more space or must be deleted.

When a ZFS snapshot is marked, then changes to existing blocks in the snapshot as well as new writes all go to free space in the disk. There is no pre-allocated space within which these COW changes are written to.

Thus, we could have a single ZFS snapshot marked today followed by years of data being written to. This is not the intent of an LVM snapshot and the warning that I had quoted above is worth reviewing once.

[regexorcist]

That would be a thinly-provisioned snapshot in LVM.

[solarengineer]

Thank you. I went back to the link I shared and saw that there is section just below on thin provisioning via snapshots.