Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 May 2005 13:26:46 -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:  <429B3EC6.7000905@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

Up and again,

   a little more testing showed that "compression enabled" is slower and 
fits *less* data than having it disabled.
  I dumbly didnīt save the screen results, but I can repeat the tests 
and post the exact messages, if needed. For now, what I can say is 
compression dropped the transfers from about 11,8 MB/s to 10MB/s and 
reduced the capacity from about 95GB to 85GB. I repeated 2 times each 
test, with little variation, and maintained block sizes of 64kb, 
filtering with dd:
To store:
# dd if=/home/bkp/backup_050425.tar of=/dev/esa0 bs=64k

To restore:
# tar -b 128 -xvOf /dev/esa0 | dd of=/dev/null


  Note: I donīt know if the tape rewinding+ejection time counted in the 
total time. I used /dev/null to be sure HD performance would not 
interfere. In fact, writing to the tape was about 1% slower than reading.
   Would this be expectable?

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
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>freebsd-hardware@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
>To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org"
>  
>


Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?429B3EC6.7000905>