Project

General

Profile

Bug #6655

ZFS recv gets confused about receive_resume_token when -F is used.

Added by Jorgen Lundman over 4 years ago.

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

Also available in: Atom PDF