Re: [PARPORT] Re: Attention anyone using the pt driver

From: J. Scott Berg (
Date: Fri Jun 15 2001 - 01:20:29 EDT

  • Next message: Sébastien Cottalorda: "[PARPORT] Accessing parport"

    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                 
    12 ROLLING HILLS DR                     (631) 924-8613
    RIDGE NY  11961

    -- To unsubscribe, send mail to: -- -- 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