Project

General

Profile

Bug #6111

zfs send should ignore datasets created after the ending snapshot

Added by Chip Schweiss about 4 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2015-08-10
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

If you create a zfs child folder, zfs send returns an error when a recursive incremental send is done between two snapshots made prior to the folder creation.

The problem can be reproduced with the following steps.

root@zfs:/# zfs create pool/test
root@zfs:/# zfs snapshot pool/test@snap1
root@zfs:/# zfs snapshot pool/test@snap2
root@zfs:/# zfs create pool/test/child
root@zfs:/# zfs send -R -I pool/test@snap1 pool/test@snap2 > /dev/null
WARNING: could not send pool/test/child@snap2: does not exist
WARNING: could not send pool/test/child@snap2: does not exist
root@zfs:/# echo $?
1
root@zfs:/# zfs snapshot -r pool/test@snap3
root@zfs:/# zfs send -R -I pool/test@snap1 pool/test@snap3 > /dev/null
root@zfs:/# echo $?
0
root@zfs:/# zfs send -R -I pool/test@snap2 pool/test@snap3 > /dev/null
root@zfs:/# echo $?
0         

Since pool/test/child was created after snap2, zfs send should not expect snap2 to be in pool/test/child when doing a recursive send. It should examine the compare the creation time of the snapshot and each child folder to decide if the folder will be sent. The next incremental send between snap2 and snap3 would properly create the child folder and snap3 which first appears in the child folder.

The problem is identical if '-i' is used instead of '-I'.


Related issues

Related to illumos gate - Bug #8896: Fix for 6111 breaks recursive send when snapshot intentionally deleted.New2017-12-06

Actions

History

#1

Updated by Joshua M. Clulow over 3 years ago

  • Subject changed from zfs send should ignore folders created after the ending snapshot to zfs send should ignore datasets created after the ending snapshot
#2

Updated by Electric Monk over 3 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

git commit 4a20c933b148de8a1c1d3538391c64284e636653

commit  4a20c933b148de8a1c1d3538391c64284e636653
Author: Alex Deiter <alex.deiter@nexenta.com>
Date:   2016-05-11T23:31:37.000Z

    6111 zfs send should ignore datasets created after the ending snapshot
    Reviewed by: Alex Aizman alex.aizman@nexenta.com
    Reviewed by: Alek Pinchuk alek.pinchuk@nexenta.com
    Reviewed by: Roman Strashkin roman.strashkin@nexenta.com
    Reviewed by: Matthew Ahrens <mahrens@delphix.com>
    Reviewed by: Paul Dagnelie <pcd@delphix.com>
    Approved by: Garrett D'Amore <garrett@damore.org>

#3

Updated by Duane Leslie about 2 years ago

I have just discovered this change when I updated to FreeBSD 11, and I have to say that it breaks behaviour I relied upon previously, namely that datasets without the `snap2` snapshot would be skipped (with a warning) but the send would be completed. An example of this behaviour is provided in the official Oracle documentation at https://docs.oracle.com/cd/E26502_01/html/E29007/recover-3.html (see step 3).

The new behaviour created by this change now aborts the send in its entirety, whereas previously the send would complete with a non-zero return code.

#4

Updated by Marcel Telka almost 2 years ago

  • Related to Bug #8896: Fix for 6111 breaks recursive send when snapshot intentionally deleted. added

Also available in: Atom PDF