Date: Wed, 1 Oct 2014 06:57:22 -0700 From: John Terrell <john.terrell@gmail.com> To: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: zfs-send/receive between FreeBSD10 and SmartOS (Illumos) fails. Message-ID: <2CAB03AD-B755-4F85-A6CA-E30B76517269@gmail.com> In-Reply-To: <A8E17D19-D4F2-4D9F-997F-CC5A18DB5358@gmail.com> References: <37BD986A-9B05-4CE8-9D55-CAB4B2713D9D@gmail.com> <CADBaqmgfR2cMmhHFd2KXBBpU8Wh3o%2BTk0Oie8fkAf8v25rsxLQ@mail.gmail.com> <99C93627-2B9C-423F-9C3D-D8B6ACB9C74A@gmail.com> <5C3F3898-9C40-48A6-9B8D-C2118448BE42@gmail.com> <CAOeNLupXqHo-4OZh58busZDCi_i_eWoYSfYZzdx7t2TLLCu7ew@mail.gmail.com> <A8E17D19-D4F2-4D9F-997F-CC5A18DB5358@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Eureka! I think I=92ve found the issue and it=92s nothing to do with = ZFS - it=92s an infrastructure problem. I was running another test = last night and just happened to be watching about two hours into the = test when the Mac I use to connect to the network suddenly (and = unexpectedly) lost connectivity for about five seconds. When it came = back, the SSH connection was intact but the ZFS transfer in progress = immediately failed. I=92m not sure if this is a DHCP lease = re-aquisition or what but to see if this is indeed the problem, I gave = the Mac a manual IP address and started the transfer over night. As of = now, it=92s been running for about 7 hours without issue. I=92m not = quite ready to call it solved until this transfer completes successfully = but this is the furthest it=92s gotten. On Sep 30, 2014, at 8:02 PM, John Terrell <john.terrell@gmail.com> = wrote: > Sure. On the SmartOS (receiving) side: >=20 > [root@smartos /]# zpool get all zones | grep feature@ > zones feature@async_destroy enabled = local > zones feature@empty_bpobj active = local > zones feature@lz4_compress active = local > zones feature@multi_vdev_crash_dump enabled = local > zones feature@spacemap_histogram active = local > zones feature@enabled_txg active = local > zones feature@hole_birth active = local > zones feature@extensible_dataset enabled = local > zones feature@embedded_data active = local > zones feature@bookmarks enabled = local > zones feature@filesystem_limits enabled = local >=20 > =85on the FreeBSD 10 (sending) side: >=20 > [root@freebsd /]# zpool get all tank | grep feature@ > tank feature@async_destroy enabled = local > tank feature@empty_bpobj active = local > tank feature@lz4_compress active = local > tank feature@multi_vdev_crash_dump enabled = local >=20 >=20 > So, the FreeBSD side is a subset of the SmartOS side. >=20 >=20 > On Sep 30, 2014, at 7:51 PM, Rich <rincebrain@gmail.com> wrote: >=20 >> It's possible that your feature flags and the receiving end's aren't >> compatible - can you show us a zfs get all tank on both sides? >>=20 >> - Rich >>=20 >> On Tue, Sep 30, 2014 at 10:39 PM, John Terrell = <john.terrell@gmail.com> wrote: >>> By the way, here's another report that sounds similar to mine = (though on Linux): >>>=20 >>> = http://stackoverflow.com/questions/19754375/why-does-zsh-send-fail-midway >>>=20 >>> His repro doesn't even use ssh (appears to be completely local). >>>=20 >>>=20 >>> On Sep 30, 2014, at 6:41 PM, John Terrell <john.terrell@gmail.com> = wrote: >>>=20 >>>> Sorry for the tardy response (busy at work. :)). Here's the = command and output (run from the SmartOS box): >>>>=20 >>>> ssh -c arcfour256 root@freebsdnas zfs send -R tank@daily20140920 | = zfs receive -v -F zones/tank >>>>=20 >>>> The output (after running for a long time xferring data): >>>>=20 >>>> receiving full stream of tank@daily20140920 into = zones/tank@daily20140920 >>>> received 1.35GB stream in 15 seconds (91.9MB/sec) >>>> receiving full stream of tank/photography@daily20140920 into = zones/tank/photography@daily20140920 >>>> Read from remote host nas00: Connection reset by peer >>>> cannot receive new filesystem stream: invalid backup stream >>>>=20 >>>>=20 >>>> Is it possible the command is simply timing out for some reason and = closing the connection? >>>>=20 >>>>=20 >>>> On Sep 26, 2014, at 3:04 PM, Will Andrews <will@firepipe.net> = wrote: >>>>=20 >>>>> What do the zfs commands print? The -v option prints some metadata = that might help diagnose the problem. >>>>>=20 >>>>> --Will. >>>>>=20 >>>>> On Monday, September 22, 2014, John Terrell = <john.terrell@gmail.com> wrote: >>>>> Hello all, I'm trying to replicate one of the ZFS filesystems that = lives on my FreeBSD 10 NAS to a SmartOS (Illumos based) server. The = transfer dies at about the 1.7TB (of almost 4TB) mark indicating: >>>>>=20 >>>>> "cannot receive incremental stream: invalid backup stream" >>>>>=20 >>>>> The stream being sent is not incremental so I'm not sure what the = receiver is trying to do. Here's the command I'm using to transfer = (executed on the SmartOS machine): >>>>>=20 >>>>> ssh root@fbsd10 zfs send -v -R tank@daily20140920 | zfs receive -v = tank >>>>>=20 >>>>> I've also tried to use mbuffer as the transport interface = (removing SSH from the equation) and it has the same result. >>>>>=20 >>>>> Is the possibly an incompatibility between FreeBSD10 and SmartOS = ZFS implementations? >>>>> _______________________________________________ >>>>> freebsd-fs@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >>>>> To unsubscribe, send any mail to = "freebsd-fs-unsubscribe@freebsd.org" >>>>=20 >>>=20 >>> _______________________________________________ >>> freebsd-fs@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >>> To unsubscribe, send any mail to = "freebsd-fs-unsubscribe@freebsd.org" >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2CAB03AD-B755-4F85-A6CA-E30B76517269>