On Thu, 14 Jun 2001, Russel Ingram wrote:
> On Fri, 15 Jun 2001, J. Scott Berg wrote:
>
> > On Thu, 14 Jun 2001, Russel Ingram wrote:
> >
> > > On Thu, 14 Jun 2001, Russel Ingram wrote:
> > >
> > > > I have added some extra functionality to the pt driver and am looking for
> > > > people to test it. The attached patch will add the following magnetic
> > > > tape ops to the driver:
> > > >
> > > > MTRETEN -- retention the tape
> > > > MTLOAD -- load the tape
> > > > MTUNLOAD -- unload the tape
> > > > MTERASE -- erase the tape
> > > > MTWEOF -- write end of file marker
> >
> > Ah, MTWEOF. I messed with this a while back and kept intending to get
> > back to this but never did. Filemarks are sufficiently tricky that
> > when I last messed with them (2.2.8?) the SCSI and IDE tape drivers
> > did different things. I got confused and never got around to
> > resolving the confusion. The tricky part is that a write operation
> > followed by most any other operation really needs a filemark to be
> > written. I believe the problem was whether a write operation followed
> > by MTWEOF wrote one or two filemarks. Or something like that.
> > Anyhow, the difference revolved around whether one or two filemarks
> > got written (in the QIC-157 sense). And then the behavior of MTFSF
> > and MTBSF, including which side of the filemark you ended up on, and
> > whether one filemark was really two QIC-157 marks.
> >
> > Anyhow, you can tell that 1) the memories are fuzzy, and 2) I'm a bit
> > confused. We (someone?) should probably figure out/decide what the
> > "right thing" to do is and try to make all the tape drivers do the
> > same thing, so that backup software writing a TR-4 tape on a SCSI
> > drive can read it back transparently on a parallel port drive.
>
> Actually, AFAICT, the whole weof process is taken care of by the drive and
> the QIC157 specifications. There's no real fiddling that has to be done,
> just send the command and the protocol and drive do the work. The same
> goes for the fsf and bsf commands.
It's a bit trickier than that, as you can see in both pt.c as well as
in ide-tape.c (it's hard to see anything at all from st.c!). Let's
say you are writing data, then you do a bsf. You must send a weof to
the tape drive before executing the bsf, otherwise you have two
overlapping data streams. pt.c already does this when you read after
writing. So, the question is under what circumstances does one send
that weof? If you're not careful you can write two filemarks (i.e.,
send two weof's to the drive), and one of the drivers (st or ide-tape)
may do so in some cases.
If my memory is correct, I think the way to see the difference between
st.c and ide-tape.c is to do the following: first, you need and ide
tape drive, and SCSI tape, IDE tape, and ide-scsi modules compiled.
Write a short program that writes a block to the tape, and then sends
an MTEOF, and then maybe another block of data and then MTEOF again.
Then read back the data from the tape, preceded by varying numbers of
fsf's. What I recall was that depending on which driver wrote the
tape and which one read it back, one got different results (i.e., read
an empty block because one was sitting between two consectuive
filemarks, versus reading a block of data). Unfortunately I don't
have an IDE tape drive at my disposal at the moment to try to
reproduce this. Maybe I needed to intersperse an MTBSF to make this
happen, I don't recall. As I said, I never got around to sorting this
out. It may even be fixed by now for all I know.
-Scott Berg
-- J. Scott Berg jsberg@earthlink.net 12 ROLLING HILLS DR (631) 924-8613 RIDGE NY 11961-- To unsubscribe, send mail to: linux-parport-request@torque.net -- -- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Fri Jun 15 2001 - 01:21:51 EDT