]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit - contrib/unbound/libunbound/python/examples/reverse-lookup.py
MFV r329807:
authorAlexander Motin <mav@FreeBSD.org>
Thu, 22 Feb 2018 04:01:55 +0000 (04:01 +0000)
committerAlexander Motin <mav@FreeBSD.org>
Thu, 22 Feb 2018 04:01:55 +0000 (04:01 +0000)
commit03d54eb339391b451a9625aef0b5c2e967bc30ab
treec27c574b89b8d18f848a3f50899d02942c3eff49
parent011eae6c576481685784c6e0afec414c5af92e19
parent34ff7cee7a460f9a00f0b1bd170b791a4840d83d
MFV r329807:
8940 Sending an intra-pool resumable send stream may result in EXDEV

illumos/illumos-gate@544132fce3fa6583f01318f9559adc46614343a7

"zfs send -t <token>" for an incremental send should be able to resume
successfully when sending to the same pool: a subtle issue in
zfs_iter_children() doesn't currently allow this.

Because resuming from a token requires "guid" -> "dataset" mapping
(guid_to_name()), we have to walk the whole hierarchy to find the right
snapshots to send.
When resuming an incremental send both source and destination live in the
same pool and have the same guid: this is where zfs_iter_children() gets
confused and picks up the wrong snapshot, so we end up trying to send an
incremental "destination@snap1 -> source@snap2" stream instead of
"source@snap1 -> source@snap2": this fails with an "Invalid cross-device
link" (EXDEV) error.

Reviewed by: Paul Dagnelie <pcd@delphix.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Approved by: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>
Author: loli10K <ezomori.nozomu@gmail.com>
cddl/contrib/opensolaris/lib/libzfs/common/libzfs_iter.c
cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c