Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!bu.edu!m2c!wpi.WPI.EDU!wpi!aej From: aej@manyjars.WPI.EDU (Allan E Johannesen) Newsgroups: comp.unix.ultrix Subject: Re: tlz04 density Message-ID: Date: 17 May 91 22:19:45 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@wpi.WPI.EDU (News) Organization: Worcester Polytechnic Institute, Worcester, MA 01609-2280 Lines: 28 In-Reply-To: olson@anchor.esd.sgi.com's message of 17 May 91 07: 52:40 GMT Nntp-Posting-Host: manyjars.wpi.edu 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. I did no other experiments, having no other uses for the drive. I had assumed there was some IRG-similar situation at work here, since ~10% more data will fit at the larger blocksize; since this is apparently not due to gaps, it must be due to something else.