On Fri, 15 Jun 2001, J. Scott Berg wrote:
> 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
I guess I didn't look at the code for writing data closely enough to
notice that it was writing an eof when it was done. That would explain
how the driver was even functional for dump and tar before I added the
case for MTWEOF. I haven't studied enough about this to say that it is
supposed to be done one way or another really, but it seems to me that the
functionality of the mtops should be included as cases to the switch that
catches those ioctls in the driver code. It should be up to the
individual application to send the ioctls that it needs at the right time.
In other words have the pt_write_fm() function and MTWEOF as a case that
is caught when that ioctl is sent by the application. This is actually
partially how I figured out that the driver didn't have weof implemented
correctly. I tried running xfsdump with it and xfsdump kept core dumping
on me. Turns out it was because it was sending the ioctl for the weof
mtop and since there was no case for MTWEOF linking back to pt_write_fm()
the ioctl would issue a "Unimplemented mtop" error message and xfsdump
didn't know what to do.
Russ
-- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com-- 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 - 10:59:33 EDT