Date: Wed, 6 Mar 2013 16:20:24 -0600 (CST) From: Larry Rosenman <ler@lerctr.org> To: Ronald Klop <ronald-freebsd8@klop.yi.org> Cc: tevans.uk@googlemail.com, freebsd-fs@freebsd.org Subject: Re: zfs send/recv invalid data Message-ID: <alpine.BSF.2.00.1303061619290.92282@thebighonker.lerctr.org> In-Reply-To: <op.wtjh0obo8527sy@212-182-167-131.ip.telfort.nl> References: <7c93aef20a88cdbcca85739e67470dce@webmail.lerctr.org> <op.wthqmth68527sy@212-182-167-131.ip.telfort.nl> <25894116c93a59dab1fd976b425c36d1@webmail.lerctr.org> <07b59d5d4b2a3dab1385b054eea4f2da@webmail.lerctr.org> <A3EA720372254541BCCB6C92DBA36A0E@multiplay.co.uk> <7619c6383449c7a316edb1cdffc98c54@webmail.lerctr.org> <alpine.BSF.2.00.1303052052300.52489@thebighonker.lerctr.org> <473BCD0A4A7A4E6AB08409A9B0C82363@multiplay.co.uk> <d7c08e218ef301f1202354d0b11a6742@webmail.lerctr.org> <CAFHbX1LC25pyOBUGJ-PFxzTOXvJPYOF15H0%2BfTk6qfCyT-Q8fA@mail.gmail.com> <6dcfb2284551025af3cf58703a2b5cdc@webmail.lerctr.org> <920990505611cd96a075c80d06691bb0@webmail.lerctr.org> <201303061857.r26IvLnc024186@higson.cam.lispworks.com> <fc81037894dbc014853ba8fed06e427f@webmail.lerctr.org> <9e133e088f6c3c3dafdc0a99eb7c48c1@webmail.lerctr.org> <op.wtjh0obo8527sy@212-182-167-131.ip.telfort.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 6 Mar 2013, Ronald Klop wrote: > On Wed, 06 Mar 2013 20:15:02 +0100, Larry Rosenman <ler@lerctr.org> 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 <ler@lerctr.org> >>>>>>> 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 > > <guess> > 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. > </guess> > > 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: Hrm. Anyone have an idea on what to do with ktrace or dtrace or gdb or whatever to debug this? I'm at a loss on where to start on it :( -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1303061619290.92282>