Bug #891
closed
'ZFS send' doesn't send clones correctly
0%
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
Updated by Rich Lowe about 12 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?
Updated by Mike La Spina about 12 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.
Updated by Garrett D'Amore about 12 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.