Date: Tue, 09 Dec 1997 18:37:39 -0600 From: David Kelly <dkelly@hiwaay.net> To: freebsd-scsi@freebsd.org Subject: Re: Questions about mt and SCSI subsystem Message-ID: <199712100037.SAA25972@nospam.hiwaay.net> In-Reply-To: Message from "Scott Watters" <scott.watters@vina-tech.com> of "Tue, 09 Dec 1997 13:27:42 PST." <007601bd04e9$48a33af0$4560f2cf@curious.vina-tech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Is this the kind of thing the CAM code is addressing? I too am very interested in improving tape handling. Went so far as to order (and get) Seagate's DAT SCSI manual (it was free, I like Seagate) and told the boss to order the Exabyte manual ($55) but Nobody Has Bothered Yet. To get my feet wet, started by porting tcopy from FreeBSD to Irix. Found big differences in tape handling between Irix 6.2 and 6.3. Other fires popped up so I haven't been back to that in weeks but the boss agreed it was promising enough that I've snagged an SGI R5000 O2 and a couple 8mm Exabyte 8505's. Darn it, those Exabytes sure look nice and work well on my FreeBSD system. Along with two 4mm's. Needless to say, at work we like tape. If I can get a couple of things worked out with FreeBSD, tcopy, Exabyte, Seagate 4mm's, and Qualtech (? Kennedy) 9-track tape drives, then I'll have homes for about 10 FreeBSD systems as tape copy stations. Currently we use Sun's because they come with tcopy and SGI doesn't. Before I came along nobody ever heard of FreeBSD. They are getting earfuls now. 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. 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. 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. 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. 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. 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. -- 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712100037.SAA25972>