guy@auspex.uucp (Guy Harris) (05/24/90)
From: guy@auspex.uucp (Guy Harris) >I am interested in finding out the current state of standards efforts >in regards to tape drivers, specifically: > >Is there any standard ioctl interface to take advantage of the flexibility >afforded by the SCSI interface? There's a *de facto* semi-standard (as in "there are probably retrograde systems that do it differently but no better, and are definitely systems that don't do it at all"), namely the "ioctl"s provided by 4.xBSD. They don't "take advantage of the flexibility afforded by the SCSI interface" in the sense that they let you do stuff that works only on SCSI tapes; the "ioctl"s include one to perform "special functions", including spacing forwards and backwards by files and by blocks, rewinding, rewind-and-unload, etc., but you can do those on non-SCSI tape drives as well. >I have heard rumors that AT&T has come up with a proposal (or perhaps a >de-facto standard in SVR4), but don't have any details. Can anyone >supply me with some? All I know of is that AT&T provides, in the "Berkeley compatibility" package, the 4.xBSD (or maybe SunOS 4.x, derived from 4.xBSD) "mt" command, and it probably uses the BSD "ioctl"s. They provide <sys/mtio.h> (the include file that defines those "ioctl"s, and the commands they perform and data structures they use), but only as part of the compatibility package, not as an official part of S5R4. In fact, the S5R4 "BSD/XENIX(R) Compatibility Guide" says, about the "mt" command: Both rely in a set of "ioctl"s that are not present in default UNIX System V. However, users with new or enhanced device drivers may take advantage of this command. Which means that, if you want to provide them with your S5 port, you can do so; if you're going to provide "ioctl"s of that sort, it's probably best to provide the BSD ones or ones based on them. >Is there any standard action for what a tape driver should do with >internal flags (End-Of-Media, Filemark, etc.) when it receives an ioctl >call (like, clear the "DataWritten" flag so filemark writing won't be >performed after an ioctl)? No official one; the drivers I know of tend to clear the "data written" flag after repositioning the tape. >Is there any standard defined for what drivers should do with the >bp->b_blkno? Early AT&T drivers (the Kennedy tape drive?) would >support block device IO to tapes, and would space the requested number >of 512-byte blocks if the b_blkno didn't match the driver's idea of >where it was. So what happens with, say, 5K blocks on a 1/2" tape >reel? Or should the driver just ignore the bp->b_blkno field >altogether? Some drivers use it, some ignore it. I wouldn't go out of my way to pay attention to it; it makes the driver more complicated and, given the problem you note, and the fact that most of the mag tape use I'm familiar with involves programs that don't seek around the tape, and the fact that seeking on mag tapes is generally rather slow, I doubt it actually makes life any better if the driver *does* try to pretend that "lseek()" works on a mag tape. Another disadvantage of the block device is that it has to pick some arbitrary block size; said block size may not match the block size on the tape (unless you're talking tapes like QIC tapes with a standard block size), and may also be smaller than you'd like (512-byte blocks, which are the default, at least in most non-4.[23]BSD systems, are rather silly on 1/2" tapes, for instance). >These questions are prompted by the infamous exabyte tape drive. The BSD "ioctl"s long antedate Exabytes; they apply to all tapes, and make life nicer on all tapes. Volume-Number: Volume 20, Number 17