On Wed, 21 May 2003 at 1:08am, Stephen D. Lane wrote

> On Wed, May 21, 2003 at 12:11:13AM -0400, Jon LaBadie wrote:

> > 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.
> 
> Well, cool, then!

Err, I think Jon gotcha' again.  :)  Using hardware compression, Sony 
claims 2.6x compression for AIT, which is ridiculous.  Their 50GB 
native capacity actually means 5*10^10 bytes, but of course tapetype won't 
tell you exactly this, due to the way it works (i.e., in the real world).

> > >    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.
> 
> Not concerned, just curious - a purely academic viewpoint :)  It still
> seems large...

It's 5577 kbytes on AIT3, and I don't worry about it.

> > Check your manual again, my reading says DIP 8 on DISABLES software control.
> 
> Oddly enough, that's also what my manual says :)  DIP 8 is OFF to ENABLE
> software control, and that's how the drive was, and is, set.

'mt compression {0|1}' doesn't return anything particularly useful.  But 
you can check the drive's compression status by running 'tapeinfo' (part 
of mtx) against the generic scsi device corresponding to the tape drive.  
For my AIT3 drive, it says:

Product Type: Tape Drive
Vendor ID: 'SONY    '
Product ID: 'SDX-700C        '
Revision: '0102'
Attached Changer: No
SerialNumber: '0001323287'
MinBlock:2
MaxBlock:16777215
SCSI ID: 4
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x32
BlockSize: 0
DataCompEnabled: no
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x3
DeCompType: 0x0
Block Position: 1659707

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University