Bug #6655
ZFS recv gets confused about receive_resume_token when -F is used.
Status:
New
Priority:
Low
Assignee:
-
Category:
-
Start date:
2016-02-15
Due date:
% Done:
0%
Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:
Description
1) zfs recv -s is first used, and for whatever reason, is aborted to leave a receive_resume_token
2) decide to sent it again, using -F to "rollback" and send the whole thing (don't use receive_resume_token)
3) completed dataset now has receive_resume_token, and zfs recv -A does not remove it.
# zfs send -v BOOM/two@send | zfs recv -s BOOM/halfsent ^C # zfs get receive_resume_token BOOM/halfsent BOOM/halfsent receive_resume_token 1-a743d9fea-etc (If you try to send the whole thing again, it will helpfully tell you to use -F) # zfs send -v BOOM/two@send | ./cmd.sh zfs recv -F BOOM/halfsent # # zfs get receive_resume_token BOOM/halfsent BOOM/halfsent receive_resume_token 1-a743d9fea-etc # zfs recv -A BOOM/halfsent 'BOOM/halfsent' does not have any resumable receive state to abort
I am unsure if "-F" should (silently) remove the receive_resume_token, or if it is "zfs recv -A" that should be fixed to handle the case where -F was used.
ps. Slightly misleading error message if you accidentally include the @snapshot part of the name to -A:
# zfs recv -A BOOM/halfsent@send cannot open 'BOOM/halfsent@send': trailing slash in name
No data to display