3 ms·
A lot of these suggestions are heavily opinionated. Which is not necessarily bad, but they seem to mess with existing conventions just for the sake of it (why {
by rollcat 3y ago
A lot of these suggestions are heavily opinionated. Which is not necessarily bad, but they seem to mess with existing conventions just for the sake of it (why {pool}:{dataset}?).
> Don't make me name [...] snapshots.
You might like this little tool I wrote: https://github.com/rollcat/zfs-autosnap https://github.com/rollcat/zfs-autosnap
You put "zfs-autosnap snap" in cron hourly (or however often you want a snapshot), and "zfs-autosnap gc" in cron daily, and it takes care of maintaining a rolling history of snapshots, per the retention policy.
It's not hard writing simple ZFS command wrappers, feel free to take my code and make your own tools.
- istjohn 3y agoFair point on the {pool}:{dataset} thing. I just don't like that the same {pool} name refers to both a pool of vdevs and the top-level dataset on that pool. It makes it that little bit harder to grok the distinction. Perhaps there's a better way to emphasize that difference.
- E39M5S62 3y agoThe distinction is easy. If you're using the 'zpool' binary, you're operating on the pool. If you use the 'zfs' binary, you're operating on the dataset.
- Freaky 3y agoNice, you reminded me of my own incomplete Rust rewrite of the Ruby ZFS snapshot script I wrote about a decade ago, and this bit of yak shaving that ended up derailing me: https://github.com/Freaky/command-limits https://github.com/Freaky/command-limits I ended up finishing neither, and should pick them back up! (I snapshot in big chunks with xargs to try to minimise temporal smear - snapshots created in the same `zfs snapshot` command are atomic)