Lucio De Re <lucio@proxima.alt.za> wrote:

> I'm not sure which of these is the right forum.

netbsd-users would be my recommendation.  This message is sent there
and BCC'd to the original lists.

> Now, the above eventually resolves to the following, where everything
> bar the rcmd is executed as superuser, courtesy of setuid "backend":
> 
> 	find {something} | cpio -i {opts} | rcmd remote cpio -o {opts}

From habit and paranoia I would use an instance of dd(1) with an
appropriate obs=... option to make sure that short reads from the
network don't confuse cpio.  This may be unnecessary; I don't know how
NetBSD's cpio handles short reads.

> What's going wrong?  Well, the target cpio (on the 1.5.2 host)
> doesn't seem to understand that the operation is complete, after
> we've transferred some 7.7GBytes of data, and proceeds to consume
> 99.8% of the available CPU time once the other end of the rcmd link
> has dropped the link.  Doesn't seem to do anything with the consumed
> time, either.

Three suggestions to collect more information:

1. run ktrace on the cpio process once it is consuming CPU time in
   this way to find out what system calls it is making

2. attach a debugger and get a backtrace of the cpio process

   This will be more informative if you build a debug version of
   cpio first:

   $ cd /usr/src/gnu/usr.bin/cpio
   $ make CFLAGS=-g

3. take a network trace of the rcmd/rsh connection once cpio is
   consuming CPU time
   
> The only recommendation I'll have trouble with is to replace cpio
> with tar or pax.  Tar may be OK, but I'm not thrilled about it,

pax handles cpio format so trying pax instead of cpio on the NetBSD
side is definitely a good idea.  It is what I would try first, since
it is easiest.

Regards,

Giles