Xref: utzoo comp.periphs:3454 comp.sys.sgi:8205 comp.periphs.scsi:1861 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!orca.wv.tek.com!cd_player.wv.tek.com!bobw From: bobw@cd_player.wv.tek.com (Bob Wood) Newsgroups: comp.periphs,comp.sys.sgi,comp.periphs.scsi Subject: Re: exabyte record size limit Message-ID: <10084@orca.wv.tek.com> Date: 11 Feb 91 18:12:46 GMT References: <1991Feb8.154740.11155@helios.physics.utoronto.ca> Sender: news@orca.wv.tek.com Reply-To: bobw@orca.wv.tek.com Followup-To: comp.periphs Organization: Tektronix Inc., Wilsonville OR. Lines: 79 In article <1991Feb8.154740.11155@helios.physics.utoronto.ca>, sysmark@physics.utoronto.ca (Mark Bartelt) writes: > Path: orca.wv.tek.com!zephyr.ens.tek.com!uunet!bonnie.concordia.ca!news-server .csri.toronto.edu!helios.physics.utoronto.ca!physics.utoronto.ca!sysmark > From: sysmark@physics.utoronto.ca (Mark Bartelt) > Newsgroups: comp.periphs,comp.sys.sgi,comp.periphs.scsi > Subject: exabyte record size limit > Message-ID: <1991Feb8.154740.11155@helios.physics.utoronto.ca> > Date: 8 Feb 91 20:47:40 GMT > Organization: University of Toronto Physics/Astronomy/CITA > Lines: 20 > Xref: orca.wv.tek.com comp.periphs:3751 comp.sys.sgi:8297 comp.periphs.scsi:1862 > > I have an exabyte drive (from Dilog) on a 4D25. When I recently upgraded > to IRIX 3.3.1, I was pleased to find the /dev/{r}mt/tps*v devices: It's > nice to finally be able to read/write arbitrary-length tape records! > > However, I've found that there's a record size limit of 240k bytes. Any > attempts to write records longer than that return EINVAL. Is this just a > misfeature of the IRIX tape driver, or is it a characteristic of exabyte > drives, or a limit (general, or SGI's) on the size of SCSI transfers, or > what? And, whichever, why was 240k chosen? This is the limit specified in the Exabyte documentation. All SCSI tape drives I have seen limit the maximum variable length record size to what can be held in the drive controllers data buffer. The drive needs to be able to retry reads and writes without involving the SCSI bus and driver. I think most drives will read an entire record into local memory and check for correctness before starting the SCSI transfer. Thus the variable length record usually must fit in the on board buffer. The Exabyte has a 256k buffer. I don't know why they restrict read/write to 240k. Perhaps they use the other space for control information. I know why the above is true for a nine track drive. I am not so sure why the Exabyte must behave this way. It does not write true variable length records with a record gap between each one like a nine track. The Exabyte simulates variable length record operation on a fixed length record format. See comments below. > > For that matter, should I even care? Back in ancient times, when all we > had were half-inch drives at, say, 800 or 1600 bpi, it was worth writing > data in blocks as large as possible, to minimize the amount of tape that > was wasted in inter-record gaps. How, exactly, do exabytes separate the > physical records? And how much tape does that information use, compared > with the length of an N-byte record? The record length does not effect tape capacity of the Exabyte in the same way as a nine track tape. The Exabyte always writes 1024 byte records on the tape. Additionally it always writes 8 of these records per scan(it is a helical scan device like a VCR). (The above applies to the 2.3 gig drive, the newer drive may have different numbers) If you write anyting that is not a multiple of 1024 bytes, you lose capacity. What you lose will be the part of the last 1024 byte physcial block that was needed to pad to a multiple os 1024. The drive will put the logical record length in a header so you don't see this padding from the host. You can also lose capacity if the host does not send data to the drive fast enough. The drive must always write a complete scan of 8 1k blocks. If it runs out of data part way through a scan, It will pad the rest of the scan. Again this is transparent to the host except as lost tape capacity. I am not sure how you minimize the padding of these 8k tracks. The drive has 256k of buffering. It has some intellegence about how much data must be in the buffer before it starts or stops the drive. Mostly I don't worry about this part very much. What is really important is to use multiples of 1024 bytes. For example if you write 512 byte records, you lose 50% of the tape capacity! > > Mark Bartelt 416/978-5619 > Canadian Institute for sysmark@cita.toronto.edu > Theoretical Astrophysics sysmark@cita.utoronto.ca