Date: Wed, 24 Aug 2005 15:00:50 -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: <430CB5D2.1060103@pgt.mpt.gov.br> In-Reply-To: <068901c5a8cd$4b8a15f0$7f06000a@int.mediasurface.com> References: <1168719770.20050824183357@adeon.lublin.pl> <068901c5a8cd$4b8a15f0$7f06000a@int.mediasurface.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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" <jarek@adeon.lublin.pl> > >> I had to unpack a lot of tar archives and I occasional noticed terrible >> bad performance on freebsd5. > --------------090702060006050300040908--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?430CB5D2.1060103>