README.md : lack of support for pruning of recursive configs

[jimklimov]

I put this bit as a separate PR, because either I got something wrong (then please explain it before rejecting - so I can apply and document the use-case), or there is currently a surprise for users like me trying to migrate from time-slider and zfs-auto-snapshot :)

[coveralls]

Coverage remained the same at 85.901% when pulling 1dc773fa61a7a31f5430e210670165234c68ded8 on jimklimov:readme-noprune into 24da309d949171527eb087d8c4da468b34c3661a on oetiker:master.

[coveralls]

Coverage remained the same at 85.901% when pulling 92e4617a60cde2d29ee0b76d22dbe0928ce75945 on jimklimov:readme-noprune into ed7074ee7506f23816ddbb8255a7f0251401ec7b on oetiker:master.

[oetiker]

you might want to add a note that the purpose of the recursive setting (as it was intended originally) was to provide the ability to create consistent backup snapshots for hierarchies of filesets. THis is accomplished by telling zfs to create a recursive snapshot ... so conceptually it is not possible to exclude anything from this kind of recursion ... the transfer then happens individually, so there pruning would be possible.

another option would be to introduce a second type of recursion which does NOT use zfs recursive snapshots ...

[jimklimov]

My use-case was for the second type (or a mix of tree/single snaps where calculatable), so I can set up snapshot policy e.g. for the whole rpool, exempt swap/dump/tmp/... datasets as i think of such exceptions (don't want to waste local space on snaps of old swap, right?)

A similar case might be to apply different policies to subtrres, e.g, do snapshot some scratch location a'la tmp, but don't keep it for years unlike other rpool defaults.

[jimklimov]

Added a note about that. And about troubleshooting my way back out of local tinkering ;)

[oetiker]

thanks