Updates to an old problem. I�m splitting the original thread in 2,
since there are 2 different questions, one of which I guess is for
-hardware and the other, for -performance, then I�m x-posting this one.
Here are other things I�ve been experimenting with... first, I�ll
present the machines:
- Omega: HP ML 110, 512MB RAM, 4x80GB 7200rpm SATA in RAID5 via
HighPoint RR8120A, AIT-3 tape via Adaptec Ultra160;
- Theta: HP DL 380, 1GB RAM, [EMAIL PROTECTED] SCSI in RAID5 via HP
Smart Array 6i
Here�s what I got:
theta# /usr/bin/time -h gtar --atime-preserve --same-owner -cvpf
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
/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
10.976.153,96 Bytes/s, almost 30x faster. Should this really happen?
(And yes, I read rmt(8), but found nothing about this. :( ).
Thanks for your help;
Tulio
Tulio Guimar�es da Silva wrote:
Hi Gary,
ouch! That�s quite disappointing... :( We had already noticed this
kind of behaviour with DDS-* tapes, but we got some progress varying
the block size... and yup, I�m really using gzipped data. :S
For AIT-3, however, i thought this hardware compression was something
about using lower tape�s phisical-rolling speeds or alikes, but I
could never really find anything concrete about the methods... the
only one thing I found was they could use "variable block sizes", but
that�s all. Again, not many details. Anyway, I�m giving up the idea of
compression for now.
If something, I�m noticeing that (at least with -b 10) it becomes (a
lot) slower with time, but I guess this would be more of a question to
the -performance list.
Add: while writing this message, I remembered to check the 700V�s
"Product Specification Manual", and they mention something about
dual-partitions, but it seems something that needs to be implemented
at driver level, since it includes SCSI commands. In this case, I
would need to format the tape as a 2-partition one... any clue about
if and/or how that works on FreeBSD?
Thanks again,
Tulio
Gary Corcoran wrote:
Tulio Guimar�es da Silva wrote:
Hello again,
I�m having some trouble putting a Sony SDX-700V SCSI AIT-3 unit
to work on FreeBSD 5.3-RELEASE.
...
Besides the speed, hardware compression seems to not being
funcional either. I already tried every 4 possible dip switch
setting for compression, but I am still not able to transfer a 180GB
archive to a (should-be) 260GB medium.
I can't help you with most of your problems, but regarding the
"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.9GB
before the tape was full. Turning off hardware compression, I could fit
2GB. The problem was that I was saving already compressed multimedia
files,
and the tape drive's "compression" just added overhead and took up
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
------------------------------------------------------------------------
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
