From owner-freebsd-bugs@FreeBSD.ORG Fri Sep 7 16:00:11 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D028106564A for ; Fri, 7 Sep 2012 16:00:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 43A418FC14 for ; Fri, 7 Sep 2012 16:00:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q87G0Bsg098659 for ; Fri, 7 Sep 2012 16:00:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q87G0Bcg098646; Fri, 7 Sep 2012 16:00:11 GMT (envelope-from gnats) Resent-Date: Fri, 7 Sep 2012 16:00:11 GMT Resent-Message-Id: <201209071600.q87G0Bcg098646@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Martin Birgmeier Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C947106566C for ; Fri, 7 Sep 2012 15:53:53 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id B8DE88FC15 for ; Fri, 7 Sep 2012 15:53:53 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.5/8.14.5) with ESMTP id q87Frqia065307 for ; Fri, 7 Sep 2012 15:53:52 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.5/8.14.5/Submit) id q87Frqrj065306; Fri, 7 Sep 2012 15:53:52 GMT (envelope-from nobody) Message-Id: <201209071553.q87Frqrj065306@red.freebsd.org> Date: Fri, 7 Sep 2012 15:53:52 GMT From: Martin Birgmeier To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/171415: [zfs] zfs recv fails with "cannot receive incremental stream: invalid backup stream" X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 16:00:11 -0000 >Number: 171415 >Category: kern >Synopsis: [zfs] zfs recv fails with "cannot receive incremental stream: invalid backup stream" >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Sep 07 16:00:10 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Martin Birgmeier >Release: 8.2.0 + head as of 2012-09-01 >Organization: MBi at home >Environment: FreeBSD hal.xyzzy 8.2-RELEASE FreeBSD 8.2-RELEASE #4: Sat Aug 27 09:30:11 CEST 2011 root@hal.xyzzy:/z/OBJ/FreeBSD/amd64/RELENG_8_2_0_RELEASE/src/sys/XYZZY_SMP amd64 FreeBSD v903.xyzzy 10.0-CURRENT FreeBSD 10.0-CURRENT #1: Sat Sep 1 17:30:01 CEST 2012 root@v903.xyzzy:/usr/obj/.../hal/z/SRC/FreeBSD/head/sys/XYZZY_SMP amd64 >Description: I have a machine "hal", running release/8.2.0, which is equipped with 6 TB disks, labeled disk31..disk36. These are more or less split in half using gpart(8), yielding partitions disk31p3..disk36p3 and disk31p4..disk36p4, each slightly less than 1 TB in size. The first set of these halves, disk31p3..disk36p3, is combined into a raidz2 zpool "hal.1", yielding approximately 4 TB. This pool is used for production. It was created on 2010-10-22, with zpool version 14 and zfs version 3 ("zpool get version hal.1", "zfs get version hal.1"). The second set of these halves, disk31p4..disk36p4, is exported as iSCSI targets using net/istgt. These are used for experimental purposes. On hal, using emulators/virtualbox-ose, I run a virtual machine v903, which I usually keep quite close to head. In v903, using iscontrol(8), I import the iSCSI targets, yielding (in order) da0..da5. I want to see what will happen when I create a zpool under head and try to duplicate the file systems in hal.1 to it. To test this with the file system "hal.1/backup/databases", I start v903 and on it run: [0]# kldload iscsi_initiator.ko iscsi: version 2.3.1 [0]# for i in disk3{1..6}p4 do echo "*** $i ***" iscontrol -n ${i} || break sleep 1 done *** disk31p4 *** iscontrol[1257]: running iscontrol[1257]: (pass2:iscsi0:0:0:0): tagged openings now 0 *** disk32p4 *** iscontrol[1262]: running iscontrol[1262]: (pass3:iscsi1:0:0:0): tagged openings now 0 *** disk33p4 *** iscontrol[1267]: running iscontrol[1267]: (pass4:iscsi2:0:0:0): tagged openings now 0 *** disk34p4 *** iscontrol[1272]: running iscontrol[1272]: (pass5:iscsi3:0:0:0): tagged openings now 0 *** disk35p4 *** iscontrol[1277]: running iscontrol[1277]: (pass6:iscsi4:0:0:0): tagged openings now 0 *** disk36p4 *** iscontrol[1282]: running iscontrol[1282]: (pass7:iscsi5:0:0:0): tagged openings now 0 [0]# zpool create v903.2 raidz2 da0 da1 da2 da3 da4 da5 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) [0]# zfs create v903.2/backup [0]# rsh -n hal "zfs send -vR hal.1/backup/databases@2012-07-21.14:23:36" | zfs receive -v v903.2/backup/databases sending from @ to hal.1/backup/databases@2011-05-01.08:34:45 receiving full stream of hal.1/backup/databases@2011-05-01.08:34:45 into v903.2/backup/databases@2011-05-01.08:34:45 sending from @2011-05-01.08:34:45 to hal.1/backup/databases@2011-06-02.20:42:45 received 48.2MB stream in 13 seconds (3.71MB/sec) receiving incremental stream of hal.1/backup/databases@2011-06-02.20:42:45 into v903.2/backup/databases@2011-06-02.20:42:45 sending from @2011-06-02.20:42:45 to hal.1/backup/databases@2011-10-15.13:56:24 received 254MB stream in 70 seconds (3.63MB/sec) receiving incremental stream of hal.1/backup/databases@2011-10-15.13:56:24 into v903.2/backup/databases@2011-10-15.13:56:24 sending from @2011-10-15.13:56:24 to hal.1/backup/databases@2011-10-27.19:21:00 received 268MB stream in 75 seconds (3.57MB/sec) receiving incremental stream of hal.1/backup/databases@2011-10-27.19:21:00 into v903.2/backup/databases@2011-10-27.19:21:00 sending from @2011-10-27.19:21:00 to hal.1/backup/databases@2012-03-19.21:39:06 received 305MB stream in 82 seconds (3.72MB/sec) receiving incremental stream of hal.1/backup/databases@2012-03-19.21:39:06 into v903.2/backup/databases@2012-03-19.21:39:06 sending from @2012-03-19.21:39:06 to hal.1/backup/databases@2012-07-21.14:23:36 received 345MB stream in 101 seconds (3.42MB/sec) receiving incremental stream of hal.1/backup/databases@2012-07-21.14:23:36 into v903.2/backup/databases@2012-07-21.14:23:36 cannot receive incremental stream: invalid backup stream rsh -n hal "zfs send -vR hal.1/backup/databases@2012-07-21.14:23:36" 0.22s user 21.94s system 5% cpu 6:33.67 total zfs receive -v v903.2/backup/databases 0.02s user 5.46s system 1% cpu 6:37.24 total [1]# As can be seen, importing the snapshot created on 2012-07-21 fails. On hal, I have the following: [0]# zpool history | grep backup/databases 2010-12-04.10:37:37 zfs create hal.1/backup/databases 2011-05-01.08:34:45 zfs snapshot hal.1/backup/databases@2011-05-01.08:34:45 2011-06-02.20:42:46 zfs snapshot hal.1/backup/databases@2011-06-02.20:42:45 2011-10-15.13:56:24 zfs snapshot hal.1/backup/databases@2011-10-15.13:56:24 2011-10-27.19:21:00 zfs snapshot hal.1/backup/databases@2011-10-27.19:21:00 2012-03-19.21:39:07 zfs snapshot hal.1/backup/databases@2012-03-19.21:39:06 2012-07-21.14:23:37 zfs snapshot hal.1/backup/databases@2012-07-21.14:23:36 [0]# Googling reveals very little information about this problem, one possibility might be http://wesunsolve.net/bugid/id/7002362, but as can be seen above, this file system has never been renamed. I have tried a similar command also with another filesystem in hal.1, which already fails when receiving the first intermediate snapshot. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: