Project

General

Profile

Bug #891

'ZFS send' doesn't send clones correctly

Added by Alexander Stetsenko over 8 years ago. Updated over 8 years ago.

Status:
Rejected
Priority:
Normal
Category:
kernel
Start date:
2011-04-08
Due date:
% Done:

0%

Estimated time:
Difficulty:
Tags:

Description

This issue was discovered by Anatoliy Legkodymov on nexentastor and
reproduces on Illumos as well.
steps to reproduce:

mkfile 64m /tmp/mypool.file
mkfile 64m /tmp/backup.file
zpool create mypool /tmp/mypool.file
zpool create backup /tmp/backup.file
zfs create mypool/aabbcc
zfs snapshot mypool/aabbcc@TO_CLONE
zfs clone mypool/aabbcc@TO_CLONE mypool/clone_aabbcc
zfs snapshot mypool/clone_aabbcc@A
zfs send -Rv mypool/clone_aabbcc@A | zfs recv -e backup
sending from @ to mypool/clone_aabbcc@A
cannot receive: local origin for clone backup/clone_aabbcc@A does not exist

History

#1

Updated by Rich Lowe over 8 years ago

If the "sending from @ " is literal, it looks like it's misformatting that message too.

I'd actually thought the behaviour here is the intended behaviour, you need the origin from which the clone came as well as the clone itself, and you're not specifying any options which would cause it to be sent. What am I missing?

#2

Updated by Mike La Spina over 8 years ago

Rich, I would agree as well. This is the expected behavior IMO. A send of the base file system would need to occur first and then the clone of the base could be sent.

#3

Updated by Garrett D'Amore over 8 years ago

  • Status changed from New to Rejected

Exactly. The original/parent data set must be sent in advance, since the clone will only contain the COW differences to that.

One can imagine an RFE to be able to send the parent dataset as well, but such an RFE would need to include an explicit switch to send the entire set of dependencies.

I'm rejecting this for now.

Also available in: Atom PDF