Amanda-Users

Re: FYI: tapetype program output for AIT-2 (Sony SDX-500C), and questions regarding same

2003-05-21 00:16:33
Subject: Re: FYI: tapetype program output for AIT-2 (Sony SDX-500C), and questions regarding same
From: Jon LaBadie <jon AT jgcomp DOT com>
To: amanda-users list <amanda-users AT amanda DOT org>
Date: Wed, 21 May 2003 00:11:13 -0400
On Tue, May 20, 2003 at 07:47:08PM -0700, Stephen D. Lane wrote:
> Greetings.  I have a Sony SDX-500C AIT-2 tape drive (50 GB native).  I
> have been using the following entry for my tapetype, obtained from
> various places in the mailing list (I have no idea how this was
> originally generated):
> 
> # old - mailing list
> define tapetype AIT-2 {
>    comment "SDX-500C"
>    length 54538 mbytes
>    filemark 1541 kbytes
>    speed 2920 kps
> }

VERY unusual to have tapetype measurement greater than marketing spec.

> Its worked fine, but I haven't been pushing the capacity of the tapes
> (only writing about 40GB or so).  That's changing, however, and I'm
> concerned that the length might be too long, so I finally got around to
> (a) turning off hardware compression on the drive (DIP switch number 7
> is OFF), and (b) running the tapetype program on the drive.  Here's
> what it came up with (I edited the comment):

And DIP siwtch 8 off too?  And software selected no compression with
either mt command or with appropriate device selection?

In 2.4.4, when you upgrade, there is a new version, amtapetype.

> # new - obtained from the tapetype program
> define tapetype AIT-2 {
>    comment "SDX-500C - produced by the tapetype program - hw compression off"
>    length 48898 mbytes
>    filemark 2788 kbytes
>    speed 6074 kps
> }
> 
> My comments/questions:
> 
> 1) tapetype's output is obviously more conservative than what I've been
>    using, both in terms of the total tape length and in terms of the
>    filemark size.  I'm not sure if this is a good thing or not, the
>    obvious pros (amanda is less likely to overrun the end of the tape)
>    and cons (she won't put as much data on the tape if the tapetype
>    estimate is short) aside.  Any thoughts on this?  Can I trust
>    tapetype?  How far?  (I'm hoping to get a quick answer from someone

No, you can't trust tapetype.  It is put there just as a joke.  Gotcha.
In reality, all tapes hold about 40 percent more than the manufacturers
claim.  They hope you will buy more tapes when you think they hold less.

> 2) The speed tapetype came up with seems more in line with how I expect
>    the drive to behave, but I have read that this parameter is
>    (currently?) unused by amanda.  Is this is still correct?  (I'm
>    running 2.4.2p2, but I'm _certain_ I'll upgrade someday :).

IIRC, never has been used and still isn't.

> 3) ...
>    ..., but does
>    anyone have a quick explanation of how tapetype calculates this
>    number..?

Write 32K blocks of random data into a small number of large tape files to EOT.
Number of 32K blocks written is total size.

Rewind.

Write 32K blocks of random data into larger number of smaller tape files to EOT.

Filemark is determined from the difference in data written divided by the
difference in number of files written.

>    Also, a 2.7MB filemark seems really large (so does a
>    1.5MB filemark, for that matter... The DEC-DLT2000 tapetype in the
>    tapetypes file has a 15000 mbyte length and the file mark is only
>    8KB...).  Why might/must these be so large?

5/1000ths of 1 percent?  You are concerned about 0.005%.  If you wrote
200 dumps to the tape, it would still only take 1% of the tape for those marks.
Its effect on Amanda calculations, no matter how large, is quite small.

> 4) Using the mt commands (Red Hat 7.2) for disabling hardware
>    compression ('mt compression' and 'mt defcompression') produced no
>    discernible results.  DIP switch 8 was (and is) set to ON, which
>    (according to the manual) should allow software manipulation of the
>    drive's hardware compression setting (e.g. the mt commands should do
>    what I'd expect them to), but it's not clear from the mt man page
>    how they're even supposed to work ('mt defcompression -1' is
>    supposed to turn it off and survive tape changes...), and there was
>    no way for me to tell if anything was happening (e.g. 'mt status'
>    never changed).  Now that HW compression is (supposedly :) turned
>    off at the HW level (via DIP switch 7), I'm Just Not Going To Worry
>    About It, but I'm wondering if anyone can share further insight into
>    how mt is supposed to work, meaning, does anyone know what the exact
>    correct syntax of these mt commands should be, and is there some way
>    I can tell if running them actually did anything, short of trying to
>    put more bits on the tape..?

Check your manual again, my reading says DIP 8 on DISABLES software control.


-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)