>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 [email protected]:/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 [email protected]:/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/[email protected]:23:36" | zfs receive -v v903.2/backup/databases sending from @ to hal.1/backup/[email protected]:34:45 receiving full stream of hal.1/backup/[email protected]:34:45 into v903.2/backup/[email protected]:34:45 sending from @2011-05-01.08:34:45 to hal.1/backup/[email protected]:42:45 received 48.2MB stream in 13 seconds (3.71MB/sec) receiving incremental stream of hal.1/backup/[email protected]:42:45 into v903.2/backup/[email protected]:42:45 sending from @2011-06-02.20:42:45 to hal.1/backup/[email protected]:56:24 received 254MB stream in 70 seconds (3.63MB/sec) receiving incremental stream of hal.1/backup/[email protected]:56:24 into v903.2/backup/[email protected]:56:24 sending from @2011-10-15.13:56:24 to hal.1/backup/[email protected]:21:00 received 268MB stream in 75 seconds (3.57MB/sec) receiving incremental stream of hal.1/backup/[email protected]:21:00 into v903.2/backup/[email protected]:21:00 sending from @2011-10-27.19:21:00 to hal.1/backup/[email protected]:39:06 received 305MB stream in 82 seconds (3.72MB/sec) receiving incremental stream of hal.1/backup/[email protected]:39:06 into v903.2/backup/[email protected]:39:06 sending from @2012-03-19.21:39:06 to hal.1/backup/[email protected]:23:36 received 345MB stream in 101 seconds (3.42MB/sec) receiving incremental stream of hal.1/backup/[email protected]:23:36 into v903.2/backup/[email protected]:23:36 cannot receive incremental stream: invalid backup stream rsh -n hal "zfs send -vR hal.1/backup/[email protected]: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/[email protected]:34:45 2011-06-02.20:42:46 zfs snapshot hal.1/backup/[email protected]:42:45 2011-10-15.13:56:24 zfs snapshot hal.1/backup/[email protected]:56:24 2011-10-27.19:21:00 zfs snapshot hal.1/backup/[email protected]:21:00 2012-03-19.21:39:07 zfs snapshot hal.1/backup/[email protected]:39:06 2012-07-21.14:23:37 zfs snapshot hal.1/backup/[email protected]: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: _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
