From owner-freebsd-fs@FreeBSD.ORG Wed Mar 6 19:36:13 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3DF30EDD for ; Wed, 6 Mar 2013 19:36:13 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews03.kpnxchange.com (cpsmtpb-ews03.kpnxchange.com [213.75.39.6]) by mx1.freebsd.org (Postfix) with ESMTP id 75F0719F for ; Wed, 6 Mar 2013 19:36:12 +0000 (UTC) Received: from cpsps-ews07.kpnxchange.com ([10.94.84.174]) by cpsmtpb-ews03.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 6 Mar 2013 20:33:37 +0100 Received: from CPSMTPM-TLF103.kpnxchange.com ([195.121.3.6]) by cpsps-ews07.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 6 Mar 2013 20:33:37 +0100 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF103.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 6 Mar 2013 20:35:03 +0100 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 62FF8678A; Wed, 6 Mar 2013 20:35:03 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Martin Simmons" , "Larry Rosenman" Subject: Re: zfs send/recv invalid data References: <7c93aef20a88cdbcca85739e67470dce@webmail.lerctr.org> <25894116c93a59dab1fd976b425c36d1@webmail.lerctr.org> <07b59d5d4b2a3dab1385b054eea4f2da@webmail.lerctr.org> <7619c6383449c7a316edb1cdffc98c54@webmail.lerctr.org> <473BCD0A4A7A4E6AB08409A9B0C82363@multiplay.co.uk> <6dcfb2284551025af3cf58703a2b5cdc@webmail.lerctr.org> <920990505611cd96a075c80d06691bb0@webmail.lerctr.org> <201303061857.r26IvLnc024186@higson.cam.lispworks.com> <9e133e088f6c3c3dafdc0a99eb7c48c1@webmail.lerctr.org> Date: Wed, 06 Mar 2013 20:35:02 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <9e133e088f6c3c3dafdc0a99eb7c48c1@webmail.lerctr.org> User-Agent: Opera Mail/12.14 (FreeBSD) X-OriginalArrivalTime: 06 Mar 2013 19:35:03.0909 (UTC) FILETIME=[B336C150:01CE1AA1] X-RcptDomain: freebsd.org Cc: tevans.uk@googlemail.com, freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 19:36:13 -0000 On Wed, 06 Mar 2013 20:15:02 +0100, Larry Rosenman wrote: > On 2013-03-06 12:59, Larry Rosenman wrote: >> On 2013-03-06 12:57, Martin Simmons wrote: >>>>>>>> On Wed, 06 Mar 2013 05:07:28 -0600, Larry Rosenman said: >>>> On 2013-03-06 04:56, Larry Rosenman wrote: >>>>> On 2013-03-06 04:51, Tom Evans wrote: >>>>>> On Wed, Mar 6, 2013 at 10:46 AM, Larry Rosenman >>>>>> wrote: >>>>>>> So, you are correct that something(tm) is unclean about the ssh >>>>>>> path. >>>>>>> >>>>>> And what is it that is added? Surely that is trivial to determine? >>>>>> echo hello > foo >>>>>> cat foo | ssh host cat >>>>>> Cheers >>>>>> Tom >>>>> it seems to be bytestream dependent, as this simple case works, and >>>>> the vast majority of the sends work, but the particular >>>>> case in the thread does NOT. >>>>> # echo hello >foo >>>>> # cat foo | ssh home cat >>>>> hello >>>>> # >>>> stranger: >>>> $ cd /tmp >>>> $ cat send.stream | ssh home openssl md5 >>>> (stdin)= 9cd1d73ea8411f1c222bc90e7bea3d33 >>>> $ openssl md5 send.stream >>>> MD5(send.stream)= 9cd1d73ea8411f1c222bc90e7bea3d33 >>>> $ >>>> so I'm not sure what is tripping it in the stream to a pipe case. >>> Is that running under the same uid? The script you posted earlier >>> runs the >>> pipe under ssh root@tbh.lerctr.org. >>> __Martin >> Ooo, good point. Would csh vs. sh make a difference? > Doesn't seem to make a difference.... > > # cat send.stream | ssh root@home openssl md5 > (stdin)= 9cd1d73ea8411f1c222bc90e7bea3d33 > # uname -a > FreeBSD thebighonker.lerctr.org 8.3-STABLE FreeBSD 8.3-STABLE #54 > r247820: Mon Mar 4 18:08:11 CST 2013 > root@thebighonker.lerctr.org:/usr/obj/usr/src/sys/THEBIGHONKER amd64 > # > # exec csh > root@borg:/home/ler # pwd > /home/ler > root@borg:/home/ler # ssh tbh "cat > /home/ler/public_html/ZFS_RECV/send.stream | ssh root@home.lerctr.org > openssl md5" > (stdin)= 9cd1d73ea8411f1c222bc90e7bea3d33 > root@borg:/home/ler # uname -a > FreeBSD borg.lerctr.org 10.0-CURRENT FreeBSD 10.0-CURRENT #124 r247826: > Mon Mar 4 19:59:08 CST 2013 > root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 > root@borg:/home/ler # > Hi, My script to send/rcv locally has a commented mbuffer in it because I had trouble with it in the past. zfs send $SEND_ARGS $VOL_FROM@$PREFIX$NEW \ | zfs receive -F $VOL_TO # | mbuffer -q | zfs receive -F $VOL_TO Maybe zfs receive expects a certain size of blocks of data and |ssh (or in my case |mbuffer) changes that. This is all a wild guess. More debugging should tell the difference, but it might give a direction to look for. The error "invalid backup stream" can be given at a couple of places. Can you use a debugger or ktrace or something else to get more information about what is happening? $ 20:32:24 ronald@sjakie [/usr/src/cddl/contrib/opensolaris/lib/libzfs/common] grep EZFS_BADSTREAM * libzfs.h: EZFS_BADSTREAM, /* bad backup stream */ libzfs_sendrecv.c: return (zfs_error(hdl, EZFS_BADSTREAM, dgettext(TEXT_DOMAIN, libzfs_sendrecv.c: error = zfs_error(hdl, EZFS_BADSTREAM, errbuf); libzfs_sendrecv.c: error = zfs_error(hdl, EZFS_BADSTREAM, errbuf); libzfs_sendrecv.c: error = zfs_error(hdl, EZFS_BADSTREAM, errbuf); libzfs_sendrecv.c: error = zfs_error(hdl, EZFS_BADSTREAM, errbuf); libzfs_sendrecv.c: return (zfs_error(hdl, EZFS_BADSTREAM, errbuf)); libzfs_sendrecv.c: return (zfs_error(hdl, EZFS_BADSTREAM, errbuf)); libzfs_sendrecv.c: return (zfs_error(hdl, EZFS_BADSTREAM, errbuf)); libzfs_sendrecv.c: (void) zfs_error(hdl, EZFS_BADSTREAM, errbuf); libzfs_sendrecv.c: (void) zfs_error(hdl, EZFS_BADSTREAM, errbuf); libzfs_sendrecv.c: return (zfs_error(hdl, EZFS_BADSTREAM, errbuf)); libzfs_sendrecv.c: return (zfs_error(hdl, EZFS_BADSTREAM, errbuf)); libzfs_sendrecv.c: return (zfs_error(hdl, EZFS_BADSTREAM, errbuf)); libzfs_util.c: case EZFS_BADSTREAM: Ronald.