From owner-freebsd-performance@FreeBSD.ORG Wed Aug 24 17:58:50 2005 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B5D216A421 for ; Wed, 24 Aug 2005 17:58:50 +0000 (GMT) (envelope-from tuliogs@pgt.mpt.gov.br) Received: from mail.pgt.mpt.gov.br (mail.pgt.mpt.gov.br [200.157.62.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D466D43D69 for ; Wed, 24 Aug 2005 17:58:45 +0000 (GMT) (envelope-from tuliogs@pgt.mpt.gov.br) Received: from [10.0.0.136] (516e.pgt.mpt.gov.br [10.0.0.136]) by mail.pgt.mpt.gov.br (8.13.1/8.13.1) with ESMTP id j7OHwhew088945 for ; Wed, 24 Aug 2005 14:58:44 -0300 (BRST) (envelope-from tuliogs@pgt.mpt.gov.br) Message-ID: <430CB5D2.1060103@pgt.mpt.gov.br> Date: Wed, 24 Aug 2005 15:00:50 -0300 From: =?ISO-8859-1?Q?Tulio_Guimar=E3es_da_Silva?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-performance@freebsd.org References: <1168719770.20050824183357@adeon.lublin.pl> <068901c5a8cd$4b8a15f0$7f06000a@int.mediasurface.com> In-Reply-To: <068901c5a8cd$4b8a15f0$7f06000a@int.mediasurface.com> Content-Type: multipart/mixed; boundary="------------090702060006050300040908" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: slow tar performance on fbsd5 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2005 17:58:50 -0000 This is a multi-part message in MIME format. --------------090702060006050300040908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, Iīve got the same kind of problem, not only with DDS-[234] tapes, but also with "all-powerful-with-bells-and-whistles" AIT-3 units, with controllers ranging from Adaptec stock 2940 to PCI-X Ultra-320... almost same results. The problems seems to lie in tar itself; I read thereīs something to do with block sizes, but using -b with larger values got me not much more than corrupt or incomplete data. :( The only way I got to have decent transfer rates AND reliability was to filter *archiving* through dd, including block sizes. For example, to archive: # tar -zcpf - /usr/local | dd of=/dev/sa0 bs=64k and to restore: # tar -b 128 -zxvf /dev/sa0 The above is particullarly true for remote transfers; if youīre using tar over rsh/rmt (-f host:/path), youīll surely prefer simple "rsh/tar" with output redirection. ;) Note that block sizes in tar count as 512-byte ones, while in dd they can be specified as Kilobytes or even megabytes. Besides speed, thereīs a sensible boost on storage space when using dd-block-sized transfers. The apparent reason for that is tar actually uses -b 20 (10kb) blocks, while 10GB+ tapes usually expect larger sizes. For AIT-3, I didnīt notice any real good improvement past 128kb block sizes; I didnīt experiment enough with DDS-4 because our test tape drive got a heart attack and quit... BTW, it returned 2 weeks ago and I didnīt give it any attention; it may be a little depressed by now, so I guess Iīll return it to test beds. :) Anyway, I wouldnīt try anything lower than 32kb blocks on it. I canīt remember if I did any test pointing to /dev/null, as mr. Hartland suggested, nor from /dev/zero or /dev/random... itīs worth a try. Iīll post new results as soon as I getīem (if any). ;) Have luck, Tulio G. da Silva Steven Hartland wrote: > Might be silly but do u get similar results if u: > 1. expand to a memory backed disk > 2. expand to /dev/null > > Steve > ----- Original Message ----- From: "JG" > >> I had to unpack a lot of tar archives and I occasional noticed terrible >> bad performance on freebsd5. > --------------090702060006050300040908--