Amanda-Users

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

2003-05-20 22:48:35
Subject: FYI: tapetype program output for AIT-2 (Sony SDX-500C), and questions regarding same
From: "Stephen D. Lane" <drsteve AT nature.Berkeley DOT EDU>
To: amanda-users list <amanda-users AT amanda DOT org>
Date: Tue, 20 May 2003 19:47:08 -0700
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
}

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):

# 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
   who already knows, rather than having to go groveling through the
   tapetype code myself...)

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 :).

3) Neither 54538 mbytes nor 48898 mbytes corresponds to 50 GB, no
   matter how I do the math (i.e. no product of 50, 1000s and 1024s
   generates either of these numbers, and 54538/50 = 1090.76 MB/GB,
   48898/50 = 977.96 MB/GB).  I'm (obviously..?) more inclined to
   believe the smaller number, given the ways of marketing, but does
   anyone have a quick explanation of how tapetype calculates this
   number..?  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?

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..?

Anyway, there's the tapetype output, which I'm probably going to start
using unless someone can come up with a compelling reason not to (e.g.
better than "you can get more bits on the tape with a larger length" :)

Any thoughts/help will be most appreciated.  Please reply to the list.

--Steve Lane               /"\
  Doudna Lab               \ /  ASCII Ribbon Campaign
  U. C. Berkeley            X     Against HTML Email