Date: Thu, 2 Oct 2014 22:13:33 -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: <4526E82D-8AEF-4A3F-B628-C26D044E331E@gmail.com> In-Reply-To: <2CAB03AD-B755-4F85-A6CA-E30B76517269@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> <2CAB03AD-B755-4F85-A6CA-E30B76517269@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ok, I=92ve confirmed this isn=92t a true ZFS send/receive issue - it is, = in fact, an environment issue here. There=92s a switch in my = environment that a few times a day goes put to lunch (disconnects) for = 5-10 seconds. This disconnection was enough to trip up the = send/receive process but not enough to disrupt the SSH session that = initiated the transfer. =20 Thanks for all of the help and sorry to randomize the discussion. On Oct 1, 2014, at 6:57 AM, John Terrell <john.terrell@gmail.com> wrote: > 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. >=20 >=20 > On Sep 30, 2014, at 8:02 PM, John Terrell <john.terrell@gmail.com> = wrote: >=20 >> 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 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4526E82D-8AEF-4A3F-B628-C26D044E331E>