While we should discuss such a more advanced filtering mechanism, I thought of the to be added `destroy -t $types` as very similar to `list -t $types | xargs zfs destroy`, where it's a union, which imho is good enough for the first iteration of this feature. I suspect most people will just want to specify whether they're destroying snapshots or filesystems/volumes. Adding more advanced filtering should probably be done for all subcommands that offer `-t` for types, right?
I think this could be a good opportunity to discuss how datasets, snapshots, -t and -d interact: Formerly, most users would learn that snapshots are descendant datasets of filesystem- and volume datasets one way or another as `zfs list` required them to specify at least -d1 or -r. In 0.8, we added code that implied -d1 when you do a plain `zfs list -t snap zroot/example1`. I'm afraid that this will increase confusion for new users who jump on ZFS without reading docs or primers, as the arcane knowledge of `-d1` or rather "snapshots are children" might be lost over time. Basically a new user's expectation for the required depth for whatever they're doing might/will be off by one. Consider how `zfs list -t filesystem zroot`'s output changes with an added `-d1` vs doing the same with `-t snap` instead, where `-d1` does nothing as it's implied and necessary already anyway. Can you blame a naive user for expecting to see snapshots of the first level descendant filesystem datasets of your root dataset with -d1 today? I'm not sure what the fix for this is; maybe it's as simple as extending the man pages a little in the right places? Theoretically one could also start handling -d differently depending on whether or not snapshots are to be displayed, but I hope we can agree not to do that as we're trying to _reduce_ confusion here. Back to zfs destroy: Imho in addition to `-t`, `zfs destroy` could actually use a depth option like `zfs list`'s `-d`, to say `zfs destroy -t snap -d1 zroot/example2` aka "destroy all snapshots of the 'example2' dataset only and nothing else". Problematically, -d has been given to deferred destroys already. In the end, a lot of these things can be resolved with multiple zfs list calls and some logic, but I've personally experienced how slow that can get when automated snapshots get out of hand; I can think of a bunch of occasions when I would've appreciated a `destroy -t snap -d1` option very, very much. Sure, destroy on snapshot ranges is a thing but costs one `list -t snap` first, which can be a horrible price to pay after things went wrong. Being able to specify the size of 'chunks' of snapshots to destroy at a time would make this perfect to recover from such situations, but I'll stop derailing here. ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T06af513a824c4d4b-M0539acc077d10dd404a53c9d Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
