Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!mips!sgi!shinobu!odin!anchor!olson From: olson@anchor.esd.sgi.com (Dave Olson) Newsgroups: comp.unix.ultrix Subject: Re: tlz04 density Message-ID: <1991May22.021825.4603@odin.corp.sgi.com> Date: 22 May 91 02:18:25 GMT References: <1991May15.012025.2766@ux1.cso.uiuc.edu> <1991May15.183245.10467@ux1.cso.uiuc.edu> <1991May17.075240.28171@odin.corp.sgi.com> Sender: news@odin.corp.sgi.com (Net News) Organization: Silicon Graphics, Inc. Mountain View, CA Lines: 40 In aej@manyjars.WPI.EDU (Allan E Johannesen) writes: | On 17 May 91 07:52:40 GMT, | olson@anchor.esd.sgi.com (Dave Olson) said: | olson> Sender: news@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.