chris@trantor.umd.edu (Chris Torek) (02/19/88)
The TM78 User's Guide says that the proper response to a Read Opposite is to issue another read command using the opposite of the previous direction (forward if the last was a read reverse; reverse otherwise). The 4.3BSD driver simply does a read reverse. Probably it is wrong. It seems, however, that after one, or perhaps several, read reverse operations, the driver winds up re-reading a previously read block. So the question: Is the 4.3BSD driver wrong once or twice? That is, is there some reason to ignore the advice in the TM78 User's Guide, or to believe that a Read Opposite will only occur once per transfer? In addition, is it necessary to issue a Forward Record operation after a successful reverse read, or will the controller do this automatically? -- In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163 (hiding out on trantor.umd.edu until mimsy is reassembled in its new home) Domain: chris@mimsy.umd.edu Path: not easily reachable
ggs@ulysses.homer.nj.att.com (Griff Smith) (02/22/88)
In article <2323@umd5.umd.edu>, chris@trantor.umd.edu (Chris Torek) writes: > The TM78 User's Guide says that the proper response to a Read > Opposite is to issue another read command using the opposite of > the previous direction (forward if the last was a read reverse; > reverse otherwise). The 4.3BSD driver simply does a read reverse. > Probably it is wrong. It seems, however, that after one, or perhaps > several, read reverse operations, the driver winds up re-reading > a previously read block. > > So the question: Is the 4.3BSD driver wrong once or twice? The driver, as released in 4.3BSD, does have a few bugs - not in error recovery that I know of. I posted fixes to comp.bugs.4bsd for the bugs that I found. I have tested the positioning code thoroughly with a tape that has intermittent read errors; the contents always match, even though the number of soft errors varies from run to run. I have also tested it with a tape that has a hard error in the middle of a block. The tape always ends up positioned after the damaged block. After using the driver for about 4 years I have seen no unexplained cases of mis-positioning. > That > is, is there some reason to ignore the advice in the TM78 User's > Guide, or to believe that a Read Opposite will only occur once per > transfer? I can't find my manual right now, but my impression is that it was misleading. My memory is that a trace of the commands from the controller was "RETRY RETRY RETRY RETRY RETRY RETRY RETRY RETRY RETRY RETRY RDOPP RDOPP RDOPP RDOPP RDOPP RDOPP RDOPP RDOPP RDOPP RDOPP RETRY". The "read opposite" refers to the sense of the original command, not to that of the retry. Since the driver does not support "read reverse" as a user-specified command, "Read Opposite" can only mean read backwards. > In addition, is it necessary to issue a Forward Record > operation after a successful reverse read, or will the controller > do this automatically? The controller will position automatically. > -- > In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163 > (hiding out on trantor.umd.edu until mimsy is reassembled in its new home) > Domain: chris@mimsy.umd.edu Path: not easily reachable One likely explanation for your problem: you may have a one-way tape. I have occasionally seen bad blocks that don't look like records when read backward. When the controller backs up to re-read the block, it skips to the good block that preceeds the block in error. This block is then successfully read, and the error is assumed to be corrected. When the drive hits the bad block again, the cycle start over. -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: 1-201-582-7736 UUCP: {allegra|ihnp4}!ulysses!ggs Internet: ggs@ulysses.att.com
chris@trantor.umd.edu (Chris Torek) (02/23/88)
>In article <2323@umd5.umd.edu> I asked: >>Is the 4.3BSD [TU78] driver wrong once or twice? It appears I insulted the driver unnecessarily. I have yet to find a bug here, but... In article <10102@ulysses.homer.nj.att.com> ggs@ulysses.homer.nj.att.com (Griff Smith) writes: >The driver, as released in 4.3BSD, does have a few bugs - not in error >recovery that I know of. ... I spotted a nice bug in mtustart, for cooked devices (not that anyone uses these, but I was trying to figure out why we got these duplicates, and this code does seek). At the bottom it does something like if (x < y) count = y - x; else count = x - y; if (count > 0377) count = 0377; mtaddr->mtncs[MUUNIT(bp->b_dev)] = count | MT_SFORW | MT_GO; which will only ever space forward. Hm. >... The "read opposite" refers to the sense of the original >command, not to that of the retry. The TM78 User's Guide is rather ambiguous, but does imply this. -- In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163 (hiding out on trantor.umd.edu until mimsy is reassembled in its new home) Domain: chris@mimsy.umd.edu Path: not easily reachable