tlz04 density

[Dave Olson]

In <AEJ.91May17171945 at manyjars.WPI.EDU> aej at manyjars.WPI.EDU (Allan E Johannesen) writes:


| On 17 May 91 07:52:40 GMT,
| olson at anchor.esd.sgi.com (Dave Olson) said:
| olson> Sender: news at odin.corp.sgi.com (Net News)
| 
| olson> There are no interrecord gaps on DAT tapes.  That isn't the way
| olson> they work.  It doesn't really matter what block size you use,
| olson> as long as it is a multiple of 512 bytes, aside from OS
| olson> efficiency issues.
| 
| This is interesting.  I no nothing of the DAT technical details; I
| just considered myself lucky to be able to obtain one.  Lacking any
| guidelines for dump, I wrote a stupid program which writes blocks
| until it gets an error, then prints the block count.
| 
| For 10,240 byte blocks (the size which DECstations write during dump
| and rdump), I found I could write 107,528 blocks, thus 1,101,086,720
| bytes.
| 
| At a 32,768 byte blocksize (the size used by a different UNIX box
| during rdump), I found could write 39,792 blocks, or 1,303,904,256
| bytes.

Hmm; perhaps a problem with the way the driver is written, or some
brain dead firmware on the drive.

On an Archive Python, I get the same capacity (+- 200K, which could
be accounted for by just 2 write retries), no matter what block size
I use.  The tlz04 is a DDS drive, just like the Python, so it SHOULD
behave the same way; the actual way data is written on the tape is
supposed to be identical.


--

	Dave Olson

Life would be so much easier if we could just look at the source code.