kern/171415: [zfs] zfs recv fails with " cannot receive incremental stream: invalid backup stream"

[Martin Birgmeier]

The following reply was made to PR kern/171415; it has been noted by GNATS.

From: Martin Birgmeier <Martin.Birgmeier at aon.at>
To: bug-followup at FreeBSD.org, freebsd-fs at FreeBSD.org
Cc:  
Subject: Re: kern/171415: [zfs] zfs recv fails with "cannot receive incremental
 stream: invalid backup stream"
Date: Wed, 17 Oct 2012 23:50:53 +0200

 One more test with the goal of determining whether iscontrol or istgt is
 the culprit...
 
 The test setup is altered as follows: In addition to the 6 partitions
 which are being used for the zpool on v903, also v903's OS partition
 (GPT, holding /, /usr, and swap) is being exported from hal via istgt
 (i.e., as iSCSI targets). Then v903 is started as a VirtualBox client on
 a Windows 7 host, where the (now 7) partitions are included via
 VirtualBox's iSCSI facility
 (http://www.virtualbox.org/manual/ch05.html#idp17868816) as ada0 and
 ada1..ada6.
 
 This setup results in a flawless zfs receive of the sent stream, again
 checked via md5 of all files. In addition the number (but not md5) of
 files in all snapshot directories (.zfs/snapshot/*) were checked.
 
 This is a strong indication that indeed iscontrol is problematic.
 
 Regards,
 
 Martin
 
 p.s. Some observations using this setup: It is a lot faster than running
 v903 in a VirtualBox client on hal. I had to do a disk check of v903
 because it had crashed, and checking the UFS file systems / and /usr was
 in fact blazingly fast, much faster than when its containing partition
 was directly connected in hal as VirtualBox host. Also, the subsequent
 zfs import test ran with a sustained rate of approximately 23  MB/s,
 whereas with v903 on hal as host it ran with only 15 MB/s (see my
 previous test), a speed increase of 50%. One should note that in the
 setup of this test, there is a 1 Gbps Ethernet between hal as the server
 and the Windows host, whereas otherwise v903 runs directly on hal, which
 at least in theory should result in much quicker I/O.
 
 So it seems that not only iscontrol needs fixing, but VirtualBox on
 FreeBSD hosts could use some optimization.
 
 But then, FreeBSD is the work of volunteers, and at this point of my
 tests is certainly the time to thank them for all the great
 possibilities this system offers!