From owner-freebsd-performance@FreeBSD.ORG Wed Aug 24 18:31:45 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 6F7B516A41F for ; Wed, 24 Aug 2005 18:31:45 +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 BAC4543D49 for ; Wed, 24 Aug 2005 18:31:44 +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 j7OIVhwr090428 for ; Wed, 24 Aug 2005 15:31:43 -0300 (BRST) (envelope-from tuliogs@pgt.mpt.gov.br) Message-ID: <430CBD9D.8020702@pgt.mpt.gov.br> Date: Wed, 24 Aug 2005 15:34:05 -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> <430CB5D2.1060103@pgt.mpt.gov.br> In-Reply-To: <430CB5D2.1060103@pgt.mpt.gov.br> Content-Type: multipart/mixed; boundary="------------070006030104000000040300" 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 18:31:45 -0000 This is a multi-part message in MIME format. --------------070006030104000000040300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I must be working too much... I canīt see where I took the DDS-thing from... O_o Sorry, now I see itīs a disk-only operation. >X( Anyway, you could try the dd thing; something like # dd if=mysql-m.tgz | tar -zxvf - and see if it makes any diference. There was a relatively new thread in April/May dealing with poor read/write results on 5.x branch.. the primary "target" was RAID, but maybe thereīs a bunch of possible tuneups that may be applied to IDE and SCSI disks. Have you triedīem? Sorry again for the blatant misunderstanding. Tulio G. Silva Tulio Guimarães da Silva wrote: > 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. >> >> >------------------------------------------------------------------------ > >_______________________________________________ >freebsd-performance@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-performance >To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" > --------------070006030104000000040300--