Page 1 of 1

zfs receive -s has hidden problems

PostPosted: Sun Jun 12, 2016 8:38 am
by haer22
In the latest version the "receive_resume_token" was introduced. If you used zfs receive -s you could resume an interrupted zfs send from it latest safe point.

However, what was not mentioned in the man pages is that there is a special snapshot created on the receiving side called "%recv". If one did not resume the zfs send and used the receive_resume_token, one would get a dataset busy error, as the receiving dataset apparently was in the middle of something.

After pulling my hair a few times, rebooting the box in my despair I just tried to delete the last snapshot thinking there may be some trouble there. Lo and behold my surprise when it did not want to destroy it as there was another snapshot depending on it called "%recv".
Code: Select all
[ihecc:~] root# zfs destroy -n tank/zTime@2016-06-10_22.00.00--5d
cannot destroy 'tank/zTime@2016-06-10_22.00.00--5d': snapshot has dependent clones
use '-R' to destroy the following datasets:
tank/zTime/%recv

After destroying %recv everything was back to normal behavior.

Guys, is my interpretation of this new feature correct?

If I want something about this added to the man-page, to which forum would you suggest I go?

Re: zfs receive -s has hidden problems

PostPosted: Sun Jun 12, 2016 5:11 pm
by lundman
If you have aborted a resumable-send, you should either do a resume-send using the -t $token
to continue it, or, clear the half-received snapshot using zfs receive -A $filesystem