Date: Wed, 24 Aug 2005 15:34:05 -0300 From: =?ISO-8859-1?Q?Tulio_Guimar=E3es_da_Silva?= <tuliogs@pgt.mpt.gov.br> To: freebsd-performance@freebsd.org Subject: Re: slow tar performance on fbsd5 Message-ID: <430CBD9D.8020702@pgt.mpt.gov.br> In-Reply-To: <430CB5D2.1060103@pgt.mpt.gov.br> References: <1168719770.20050824183357@adeon.lublin.pl> <068901c5a8cd$4b8a15f0$7f06000a@int.mediasurface.com> <430CB5D2.1060103@pgt.mpt.gov.br>
next in thread | previous in thread | raw e-mail | index | archive | help
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" <jarek@adeon.lublin.pl> >> >>> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?430CBD9D.8020702>