From owner-freebsd-fs@FreeBSD.ORG Wed Oct 17 19:20:01 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B238D690 for ; Wed, 17 Oct 2012 19:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [8.8.178.135]) by mx1.freebsd.org (Postfix) with ESMTP id 990DD8FC17 for ; Wed, 17 Oct 2012 19:20:01 +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 q9HJK13p014486 for ; Wed, 17 Oct 2012 19:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q9HJK1b4014485; Wed, 17 Oct 2012 19:20:01 GMT (envelope-from gnats) Date: Wed, 17 Oct 2012 19:20:01 GMT Message-Id: <201210171920.q9HJK1b4014485@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: Martin Birgmeier Subject: Re: kern/171415: [zfs] zfs recv fails with " cannot receive incremental stream: invalid backup stream" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Martin Birgmeier List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 19:20:01 -0000 The following reply was made to PR kern/171415; it has been noted by GNATS. From: Martin Birgmeier To: bug-followup@FreeBSD.org, Martin.Birgmeier@aon.at, freebsd-fs@FreeBSD.org Cc: Subject: Re: kern/171415: [zfs] zfs recv fails with "cannot receive incremental stream: invalid backup stream" Date: Wed, 17 Oct 2012 21:17:26 +0200 Good news... I upgraded the FreeBSD head running in the virtual machine v903 to r241507, with the goal to see whether the problem described has been fixed in the meantime. (The server, hal, is still at 8.2 release.) In addition, instead of using iSCSI to make disk{31..36}p4 from hal appear in v903, I attached them as devices directly using VirtualBox (all to one and the same virtual SATA controller). Now the test worked, and I could successfully receive the backup stream. I even made an md5 comparison of all the files in the received file system (> 53000), which went through without a single difference. Very good! What was left was testing with the original test setup again, i.e., using iSCSI. Unfortunately, this still fails in the same way, so it seems that something with iscontrol or istgt is broken. On a hunch, I'd say it is iscontrol, simply because I assume that on the server side (ports/net/istgt) there is not that much that can break, it being a userland application, whereas iscontrol is a kernel module hooking into the SCSI subsystem. Therefore, this defect should possibly be reclassified and instead of [zfs] have some other sticker applied. Regards, Martin p.s. I am using istgt also with disk images of MS Windows XP installations, exporting them to remotely running VirtualBox instances without any issues - to me a hint that istgt is quite o.k. Of course, the zfs scenario uses 6 iSCSI targets at the same time, whereas the XP emulation uses only one, so maybe either istgt or iscontrol have problems with multiple connections/instances.