zfs holds fail delete snapshots about zfsnap HOT 5 CLOSED

@aaron-t Thanks for the bug report. I have tested this and this problem should be resolved with the latest release.

---Alex

from zfsnap.

I can't seem to find in the 2.0 or 1.11.1 where this fix would be. Can you point me in the right direction, just for my own learning purposes of how you got around this issue?

from zfsnap.

@aaron-t This fix happened quite awhile ago -- as part of the 2.0 rewrite. The fix came as part of an effort to make the code more robust so it could handle failures.

The code is in the RmZfsSnapshot() function in core.sh, but you'll note there is no code to specifically test for the holds and avoid them. Rather, zfsnap attempts to delete the snapshot and ZFS prevents it from doing so. The error is caught, printed in the console, and then the loop continues.

Since you said this was for your learning purposes, I took the liberty of looking at your patch and have a few general-purpose suggestions.

holds=$(`echo zfs holds -r $i | grep $i`)

Here, you're using both backticks () and the newer $() syntax. They both mean the same thing, and you only need to use one. zfsnap uses because it is more portable to old shells, but $() is preferable because it allows nesting. Also the "echo" isn't needed. Lastly, the cost is high to call zfs holds for each snapshot to be deleted. It'd be preferable to assemble a list of all holds of the dataset(s) zfsnap is operating on and then loop through that list as a check. The ZFS property "userrefs" is a counter of the number of holds on a given snapshot. zfs list -H -t snapshot -o name,userrefs will provide that list.

if echo $holds | grep -q -e '@'; then

This is where I'd put the check for whether the snapshot to be deleted is in the pre-assembled list of holds. A function where the list is looped over, looking for $i would be much faster and more portable than calling grep. Using pipe spawns a subshell, which slows things down, and starting a grep process for each check would also be costly. Performance often isn't a concern with shell scripting, but when looping over 10,000+ snapshots, those performance decisions add up.

I hope that helped a bit. Let me know if you have any questions. :-)

---Alex

from zfsnap.

Thank you so much for taking the time to write this. My shell scripting ability is still in the read and modify stages so to get the values I needed I did some copy paste and echoed until it came out right.

I did understand that my placement was bad, but the goal was to modify your code as little as possible and keep it in one place so that I could still update when you released a new version. At some point I'll put in the 2.0 branch so I can use it stock and let you know if anything arises.

Thanks again for an awesome script, it's a 1/2 of my snapshot/replication for my zfsguru based storage system. In addition to zfsnap, I use a much more hacked zfsrep http://www.tediosity.com/zfs-replication-on-freebsd/ to send the snapshot to my other box. I only use its functions as a library really as it was easier than starting from scratch.

from zfsnap.

Hopefully for 2.1 we'll have a zfsnap send command as well (see #48). :-) And if you like using zfsrep as a library, you might want to checkout core.sh in zfsnap. One of the hidden features of the 2.0 rewrite is that we moved much of the logic into functions all in a single library. And they come with unit tests, so they should be reliable. It can be quite useful for your own custom scripts.

---Alex

from zfsnap.