
Show HN: View and diff files in ZFS snapshots - j-keck
https://github.com/j-keck/zfs-snap-diff
======
contingencies
I wonder if snapshots on Linux _inotify()_ event detection (or similar) would
be easier. At the very least, skipping making snapshots that are exactly the
same as previous versions would be a nice feature. I implemented an
_inotify()_ based angband cheat as _perl_ script, once... no ZFS required!
Does the average home directory change more than once per 5 minutes on
average? I doubt it.

~~~
barrkel
Zfs snapshots are extremely cheap. Its storage is structured as a tree, and
changes are implemented though copy-on-write modifications from leaves to the
root of the tree. That's how it e.g. eliminates the RAID5 write hole in
software, for raidz.

Snapshots make use of this by taking another reference on that root block, so
that it isn't disposed of (turned into free space) after the next change to
the file system. That's why they're so cheap.

You should also see why this means that snapshots that are exactly the same as
the previous snapshot should be no more expensive, in principle, than an extra
hard link to a file. No more than an entry in some list somewhere, and an
increment of a digit somewhere.

A snapshot mechanism based just on inotify would be way more expensive,
without further help from the filesystem, like copy-on-write hard links. But
then, almost all the magic is in the filesystem, not inotify.

~~~
contingencies
Yes, ZFS is great, I use it myself. But technical efficiency does not equate
to programming ease, and if I'm not mistaken on Linux you need root
permissions to use ZFS snapshots right now. In addition, you are limited in
scope to people's systems running ZFS, and who have home dirs on ZFS... which
due to module-based compilation being the norm demands an initramsfs if you
want to include root's home... and so on and so forth. It's not exactly 'no
strings attached'. My point was, _there 's more than one way to do it_
(TMTOWTDI; the perl refrain) and inotify() actually has some benefits
(portability across filesystems, non filesystem-wide scope potential, zero
storage overhead in the case of no changes between two five minute periods due
to a non-polling, event-driven architecture being some of the more obvious).

------
rodgerd
Neat tool - although I wonder whether it would be better implemented as
extensions to snapper.

~~~
mieses
Snapper does not have a web gui and does not support ZFS. This looks perfect
for freenas, zfsguru, etc. Hope to try it out. Thank you!

