Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.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: 15 May 91 15:30:57 GMT References: <1991May15.012025.2766@ux1.cso.uiuc.edu> Sender: news@wpi.WPI.EDU (News) Organization: Worcester Polytechnic Institute, Worcester, MA 01609-2280 Lines: 23 In-Reply-To: melanie@director.beckman.uiuc.edu's message of 15 May 91 01: 20:25 GMT Nntp-Posting-Host: manyjars.wpi.edu On 15 May 91 01:20:25 GMT, melanie@director.beckman.uiuc.edu (Melanie Anderson) said: melanie> Sender: usenet@ux1.cso.uiuc.edu (News) melanie> what is the 'recording density' of a TLZ04? and length? melanie> inquiring minds want to know. With a simple test program, I found I could write 107,528 10240 byte blocks to the dat before error. It would write 39,792 32768 byte blocks, if anyone cares (I have a different system which writes this different 'dump' blocksize). Anyway, using sd 12000 6520, I observed that the tape utilization is "safe". i.e. dump says " of 10240 byte blocks is of the tape", and is well under of 107,528 (of course, I imagine this number could change on different test runs even on the same tape). i.e. this is very conservative. I haven't used it on any filesystems which would test the boundary, so I haven't worked up a more accurate s/d setup; you can experiment until you find that the s/d formula yields a closer block-to-percent ratio.