Date: Tue, 9 Dec 1997 19:43:28 -0700 (MST) From: gibbs@narnia.plutotech.com (Justin T. Gibbs) To: David Kelly <dkelly@HiWAAY.net> Cc: scsi@FreeBSD.org Subject: Re: Questions about mt and SCSI subsystem Message-ID: <199712100243.TAA18226@narnia.plutotech.com> In-Reply-To: <199712100037.SAA25972@nospam.hiwaay.net> References: <199712100037.SAA25972@nospam.hiwaay.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199712100037.SAA25972@nospam.hiwaay.net>, David Kelly <dkelly@HiWAAY.net> writes: > Scott Watters wrote: >> >> I did a ktrace on mt and discovered that the driver was NOT >> returning an error on the fsf IOCTL. It looks like a driver >> problem. I've been looking at the sources, but the EOM logic >> escapes me. Has anyone else played with/patched this code? >> I know the logic is complex due to asychronous IO and early >> returns. But I can't see the forest for the trees. > > I got lost in there too. Not sure if we ever write an EOT marker but > did see somewhere in the code where we write a couple of extra EOF's to > mark where we thing the end is when we close the tape. There was also > some test for moving back toward the start of the tape that would > trigger write of EOF's. In SCSI, there is no such thing as an "EOT" marker. Instead, you must follow the convention for whatever type of tape media you are writing too for designating "EOT". This can be "nothing", a pattern of filemarks, or an erase gap. The current st driver only does the "double filemark" thing. I still need to do more research on which formats require what kind of EOT handling. > Is this the kind of thing the CAM code is addressing? The CAM code has a new tape driver and I certainly hope that it will address the problems the current st driver has. Unfortunately, I only have access to Exabyte and DDS2 drives at the moment, and it's hard to find all the details on historical tape writing conventions. > We've had several instances where Sun's tcopy didn't accurately detect > the end of tape and stopped early. Some old systems, probably VAX's, > often wrote multiple EOF's between tape files, but happily skipped over > those. Sun has a "Berkeley" tape device, aka /dev/rmt/0b, which is > supposed to deal with this. We've had egg on our face once too many > times when a tape was shipped without all its data so now we have a > manual procedure for detecting this situation and problem tapes are > marked accordingly. The Berkeley convention was that 2 filemarks in a row signaled EOT. Unfortunately, this doesn't work out so well if someone decides to write a 0 length file. The FreeBSD st driver (including the CAM one), return EIO when a filemark is encountered or a "blank check" is reported. It's up to the reading program to decide what that means. > Rough guess right now is that EOT on 8mm's is going to be a problem. > Suspect the low density 8mm format doesn't have an EOT marker. Need the > book to know if its supposed to, but empirical evidence suggests its > not there. You're supposed to get a "blank check" from the drive once you traverse beyond EOD (End of Data). > I also worry about translating an original tape's (3) EOF's between > files into a single EOF, but so far this modernization hasn't prompted > any complaints. Isn't this for the application to decide? > The other thing is the customer has developed a "statistics" fetish. > This isn't so bad as knowing the length of tape, bytes copied, etc, is > exactly the thing needed to detect premature end of tape. I can query > SGI's tape device for current position and know what block I'm on. > That's good enough. Its not hard for tcopy to count the bytes it writes > either. Meanwhile The Boss buys TTi packaged 8mm drives for twice the > street price because they have displays which show how much tape has > been used. Assuming the device supports the READ POSITION scsi command, there's no reason we can't add this feature to mt/sa(4). I believe that mjacob has already added this to NetBSD. > So far I want to enhance tcopy (and/or st(4)) to provide these > statistics and accurately detect end of tape. But further would like to > be able to write multiple copies of a tape in parallel. And would also > like to develop a disk file format whereby a tape (of unknown format) > could be stored and later reproduced. Right now, we only have a single error code to pass back to the application for filemarks, setmarks, EOD, and EOM. Either we have to add some error codes or add an MT ioctl so the application can determin what the exact cause of the EIO was. > Let me add, I like SGI's "mt" command. "mt status" is full of all kinds > of useful info (such as tape position, drive manufacturer's model #)and > its output is shorter than FreeBSD's. I like the way SGI blocks on tape > access when the drive is temporarily busy loading tape. I don't like the > nasty message FreeBSD and Solaris deliver. I don't think that the CAM driver will give you the "nasty message" since it will wait for up to a minute for a device to become ready before failing a command assuming the device returns busy status or the "in the process of becoming ready" sense key.. > -- > David Kelly N4HHE, dkelly@nospam.hiwaay.net > ===================================================================== > The human mind ordinarily operates at only ten percent of its > capacity -- the rest is overhead for the operating system. -- Justin T. Gibbs =========================================== FreeBSD - Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712100243.TAA18226>