Date: Mon, 30 May 2005 13:01:11 -0300 From: =?ISO-8859-1?Q?Tulio_Guimar=E3es_da_Silva?= <tuliogs@pgt.mpt.gov.br> To: freebsd-performance@freebsd.org Subject: rmt as a bottleneck - Was: Weird behaviour of AIT-3 and (g)tar Message-ID: <429B38C7.5040405@pgt.mpt.gov.br> In-Reply-To: <428DFF35.1000409@pgt.mpt.gov.br> References: <428CF20F.50607@pgt.mpt.gov.br> <428D0D79.7010506@rcn.com> <428DFF35.1000409@pgt.mpt.gov.br>
next in thread | previous in thread | raw e-mail | index | archive | help
--------------090500060903070709060002
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mail.pgt.mpt.gov.br id
j4UG0wnc096423
Updates to an old problem. I=B4m splitting the original thread in 2,=20
since there are 2 different questions, one of which I guess is for=20
-hardware and the other, for -performance, then I=B4m x-posting this one.
Here are other things I=B4ve been experimenting with... first, I=B4ll=20
present the machines:
- Omega: HP ML 110, 512MB RAM, 4x80GB 7200rpm SATA in RAID5 via=20
HighPoint RR8120A, AIT-3 tape via Adaptec Ultra160;
- Theta: HP DL 380, 1GB RAM, 6x72.8GB@10krpm SCSI in RAID5 via HP=20
Smart Array 6i
Here=B4s what I got:
theta# /usr/bin/time -h gtar --atime-preserve --same-owner -cvpf=20
omega:/home/teste /home/bkp/home/
gtar: Removing leading `/' from member names
home/bkp/home/
home/bkp/home/bkp/
home/bkp/home/bkp/rsh-vulcano.sh
home/bkp/home/bkp/2005-01/
home/bkp/home/bkp/2005-01/vulcano_2005-01-31.tar.gz
^Ctime: command terminated abnormally
8m24.24s real 0.15s user 0.78s sys
... and then...
omega# ls -laFG /home/teste
-rw-r--r-- 1 root wheel 189020160 May 30 12:02 /home/teste
omega#
this gives me exact 375.040 Bytes/second. then I changed my approach:
omega# /usr/bin/time -h rsh theta gtar --atime-preserve --same-owner -C=20
/home/bkp -cvpf - home/ >/home/teste1
home/
home/bkp/
home/bkp/rsh-vulcano.sh
home/bkp/2005-01/
home/bkp/2005-01/vulcano_2005-01-31.tar.gz
home/bkp/2005-01/liam_2005-01-24.tar.gz
home/bkp/2005-01/cache_www2005-01-29.tar.gz
^C 9m33.75s real 8.57s user 3m6.08s sys
omega# ls -laFG /home/teste1
-rw-r--r-- 1 root wheel 6396353720 May 30 12:35 /home/teste1
omega#
Observe that I bypassed rmt; that bumped the transfer rate to=20
10.976.153,96 Bytes/s, almost 30x faster. Should this really happen?=20
(And yes, I read rmt(8), but found nothing about this. :( ).
Thanks for your help;
Tulio
Tulio Guimar=E3es da Silva wrote:
> Hi Gary,
> ouch! That=B4s quite disappointing... :( We had already noticed this=20
> kind of behaviour with DDS-* tapes, but we got some progress varying=20
> the block size... and yup, I=B4m really using gzipped data. :S
> For AIT-3, however, i thought this hardware compression was something=20
> about using lower tape=B4s phisical-rolling speeds or alikes, but I=20
> could never really find anything concrete about the methods... the=20
> only one thing I found was they could use "variable block sizes", but=20
> that=B4s all. Again, not many details. Anyway, I=B4m giving up the idea=
of=20
> compression for now.
> If something, I=B4m noticeing that (at least with -b 10) it becomes (a=
=20
> lot) slower with time, but I guess this would be more of a question to=20
> the -performance list.
> Add: while writing this message, I remembered to check the 700V=B4s=20
> "Product Specification Manual", and they mention something about=20
> dual-partitions, but it seems something that needs to be implemented=20
> at driver level, since it includes SCSI commands. In this case, I=20
> would need to format the tape as a 2-partition one... any clue about=20
> if and/or how that works on FreeBSD?
> Thanks again,
>
> Tulio
>
> Gary Corcoran wrote:
>
>> Tulio Guimar=E3es da Silva wrote:
>>
>>> Hello again,
>>>
>>> I=B4m having some trouble putting a Sony SDX-700V SCSI AIT-3 unit=20
>>> to work on FreeBSD 5.3-RELEASE.
>>
>>
>> ...
>>
>>> Besides the speed, hardware compression seems to not being=20
>>> funcional either. I already tried every 4 possible dip switch=20
>>> setting for compression, but I am still not able to transfer a 180GB=20
>>> archive to a (should-be) 260GB medium.
>>
>>
>>
>> I can't help you with most of your problems, but regarding the=20
>> "compression"...
>>
>> I would guess that if you have 180GB to backup, it's not all text. :)
>> When I last used a tape drive years ago, when writing to a 2GB tape
>> that would supposedly hold 4GB compressed, I could fit only about 1.9G=
B
>> before the tape was full. Turning off hardware compression, I could f=
it
>> 2GB. The problem was that I was saving already compressed multimedia=20
>> files,
>> and the tape drive's "compression" just added overhead and took up=20
>> more space.
>> So unless you're backing up text or similar files, don't believe the
>> marketing hype about getting 2x the amount onto your tapes...
>>
>> Gary
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>freebsd-hardware@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
>To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.o=
rg"
> =20
>
--------------090500060903070709060002--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?429B38C7.5040405>