From nobody@FreeBSD.ORG  Thu Aug 17 02:28:17 2000
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 7E73237B446; Thu, 17 Aug 2000 02:28:12 -0700 (PDT)
Message-Id: <20000817092812.7E73237B446@hub.freebsd.org>
Date: Thu, 17 Aug 2000 02:28:12 -0700 (PDT)
From: jms@geriatrix.circlesquared.com
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@FreeBSD.org
Subject: Dreadful tar performance with remote device
X-Send-Pr-Version: www-1.0

>Number:         20674
>Category:       gnu
>Synopsis:       Dreadful tar performance with remote device
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Aug 17 02:30:00 PDT 2000
>Closed-Date:    Mon Aug 21 04:53:25 PDT 2000
>Last-Modified:  Mon Aug 21 05:18:38 PDT 2000
>Originator:     Jon Schneider
>Release:        4.1
>Organization:
>Environment:
(Not with me now but a cleanish 4.1-RELEASE)
>Description:
I initially noticed my established backup procedure was slow then found the
problem was that tar doesn't cope with remote devices very well even 
if they aren't remote. See how-to-repeat for output which shows that rsh/rcp
on its own is ok.

On a longer test the machine can be seen to be IDLE while it's taking
forever not transferring the data. This is why I think it is a bug
rather than overhead. I don't know whether it is tar or the kernel
waiting.

>How-To-Repeat:
Machine is a P233MMX...

Script started on Thu Aug 10 21:51:27 2000
bash-2.04# ls -l meg
-rw-r--r--  1 root  wheel  1048576 Aug 10 21:50 meg
bash-2.04# time rcp meg localhost:/tmp

real	0m0.374s
user	0m0.006s
sys	0m0.063s
bash-2.04# time tar cvf localhost:/tmp/fff.tar meg 
meg

real	0m10.511s
user	0m0.001s
sys	0m0.054s
bash-2.04# exit

Script done on Thu Aug 10 21:52:17 2000

The above is VERY sensitive to blocksize.
>Fix:


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: sheldonh 
State-Changed-When: Thu Aug 17 05:17:49 PDT 2000 
State-Changed-Why:  
GNU tar is not maintained by the FreeBSD project, and has its 
own mail address for reporting bugs: <tar-bugs@gnu.org>. 

It is worth noting, however, that FreeBSD ships a fairly 
old and modified version of GNU tar.  If you could try to 
build GNU tar 1.13, and see whether the problem persists, 
that would probably give us an indication as to whether 
this actually needs to be reported to the GNU folks. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=20674 

From: Jon Schneider <jms@geriatrix.circlesquared.com>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: gnu/20674: Dreadful tar performance with remote device
Date: Fri, 18 Aug 2000 16:06:44 +0100

 I've tested the packaged gnu tar 1.13 and that's about the same.
 
 I tried switching the tcp.delayed_ack sysctl to 0 and that seems to
 cure the problem. However it is still faster doing the rsh bit manually
 than letting tar do it.
 
 	Jon
 
State-Changed-From-To: feedback->closed 
State-Changed-By: sheldonh 
State-Changed-When: Mon Aug 21 04:53:25 PDT 2000 
State-Changed-Why:  
Thanks for the feedback.  Since this appears to be a problem 
that exists in the latest stock release of GNU tar, 
you should take it up with the GNU tar maintainers. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=20674 
>Unformatted:
