Date: Fri, 20 May 2005 12:16:05 -0300 From: =?ISO-8859-1?Q?Tulio_Guimar=E3es_da_Silva?= <tuliogs@pgt.mpt.gov.br> To: freebsd-hardware@freebsd.org Subject: Re: Weird behaviour of AIT-3 and (g)tar Message-ID: <428DFF35.1000409@pgt.mpt.gov.br> In-Reply-To: <428D0D79.7010506@rcn.com> References: <428CF20F.50607@pgt.mpt.gov.br> <428D0D79.7010506@rcn.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--------------040304090006010606070503 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 j4KFG74H064711 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 the=20 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 could= =20 never really find anything concrete about the methods... the only one=20 thing I found was they could use "variable block sizes", but that=B4s all= .=20 Again, not many details. Anyway, I=B4m giving up the idea of compression=20 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 at=20 driver level, since it includes SCSI commands. In this case, I would=20 need to format the tape as a 2-partition one... any clue about if and/or=20 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 t= o=20 >> work on FreeBSD 5.3-RELEASE. > > ... > >> Besides the speed, hardware compression seems to not being funcional=20 >> either. I already tried every 4 possible dip switch setting for=20 >> compression, but I am still not able to transfer a 180GB archive to a=20 >> (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.9GB > before the tape was full. Turning off hardware compression, I could fi= t > 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 --------------040304090006010606070503--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?428DFF35.1000409>